Apuntes FBD2018

Fundamentos de Bases de Datos
Instituto Tecnológico Superior de

Álamo Temapache
División de Ingeniería en Sistemas Computacionales
Ingeniería en Sistemas Computacionales
Ingeniería en Tecnologías de la Información y

Comunicaciones
Fundamentos de Base de Datos
Apuntes Recopilados por:

Tania Turrubiates López, Eng. D.
Apuntes recopilados por:

Tania Turrubiates López, Eng.D
Aportación al perfil
Esta asignatura aporta al perfil del egresado la capacidad de administrar proyectos que
involucren tecnologías de información en las organizaciones conforme a requerimientos
establecidos; diseñando, desarrollando y manteniendo sistemas de bases de datos
asegurando la integridad, disponibilidad y confidencialidad de la información
almacenada. También aporta el perfil del egresado la capacidad de desarrollar e
implementar sistemas de información para el control y la toma de decisiones utilizando
metodologías basadas en estándares internacionales.
Intención didáctica
El temario se organiza en siete unidades de aprendizaje. En la unidad uno, se abordan los
conceptos fundamentales y los componentes de un sistema gestor de base de datos,
considerando la importancia y las áreas de aplicación en la organización y el desarrollo
profesional.
En la unidad dos, se revisa el modelo Entidad-Relación como una herramienta que

permite el modelado conceptual de los esquemas de bases de datos en una forma
consistente y adecuada. La unidad tres, revisa el modelo relacional, como uno de los más
utilizados en el modelado de base de datos.
En la unidad cuatro, se asegura que el diseño de los esquemas de bases de datos

cumple con las formas normales y mantienen la adecuada integridad. En la unidad cinco,
se trabaja con álgebra relacional a un nivel de comprensión de las funciones que se
utilizan en lenguaje de consulta SQL, sin profundizar en la formalización matemática.
En la unidad seis, se realizan consultas SQL con el fin de entender la estructura de

las consultas revisando: funciones, consultas anidadas y operaciones de modificación de
las bases de datos sin profundizar, ya que el lenguaje se trabajará con mayor detalle en las
materias subsecuentes.
En la unidad siete, se revisa el paradigma orientado a objetos y sus consideraciones

en el modelado de base de datos.
Competencias a desarrollar
Esta asignatura tiene como objetivo de desarrollar en el estudiante competencias
especificas, de manera que sea capaz de:

Tania Turrubiates López, Eng.D !i
• Identificar y analizar necesidades de información para su representación,

tratamiento y automatización para la toma de decisiones.
• Diseñar esquemas de bases de datos para generar soluciones al tratamiento de
información.  
Para ello, el estudiante debe contar con competencias previas tales como:
• Identificar las estructuras básicas de las matemáticas discretas y aplicarlas en el

manejo y tratamiento de la información.
• Utilizar técnicas de modelado para la solución de problemas.
• Aplicar la sintaxis de un lenguaje orientado a objetos.
• Aplicar un lenguaje orientado a objetos para la solución de problemas.  
Bibliografía
Las fuentes bibliográficas utilizadas para recopilar estos apuntes y ejemplos fueron las
siguientes:
Carlos Coronel, Steve Morris y Peter Rob. (2011). Bases de datos. Diseño,
implementación y administración. Novena Edición. Editorial Cengage Learning.
Irene Luque Ruiz, Miguel Angel Gómez-Nieto, Enrique López Espinosa, Gonzalo
Cerruela García. (2002). Bases de datos. Desde Chen hasta Codd con Oracle. Primera
Edición. Editorial Alfaomega RA-MA.
David M. Kroenke. (2003). Procesamiento de Base de Datos. Fundamentos, diseño e

implementación. Octava Edición. Editorial Pearson Prentice Hall.

Tania Turrubiates López, Eng.D !ii
UNIDAD 1
SISTEMAS GESTORES DE BASE

DE DATOS.
Competencias especificas.
El alumno será capaz de: 
• Identificar la arquitectura, los usuarios, niveles de abstracción y lenguajes de un

sistema de gestión de bases de datos.
 

Tania Turrubiates López, Eng.D !1
Sistemas Gestores de Base Datos

El término de bases de datos no apareció hasta a mediados de los años setenta, época en la
cual la información era representada haciendo uso de un conjunto de archivos
generalmente planos, es decir, sin formato. Estos archivos no estaban relacionados entre
si y los datos almacenados representaban relaciones existentes en la información
mediante referencias simbólicas y/o físicas. La redundancia era grande y la integridad de
la información representada dejaba mucho que desear.
Aún así, muchos desarrolladores de software bautizaban a sus sistemas de archivos

como base de datos, sin preocuparse de que cumplieran o no una serie de propiedades que
deben de acompañar al uso de este termino, cualidades que se describirán mas adelante.
Antecedentes
Sistemas de procesamiento de archivos
La mejor forma de entender la naturaleza y características de las bases de datos actuales
es ver las particularidades que precedieron al uso de la tecnología de bases de datos, los
primeros sistemas de información almacenaban grupos de registros en archivos
preparados.
Estos sistemas de procesamiento de datos representan una significativa mejoría

sobre los sistemas manuales de registro, aunque con las siguientes limitantes:
• Datos separados y asilados: Era difícil combinar datos del archivo cliente con el
archivo bote en un solo archivo sencillo. Los analistas de sistemas y los
programadores debían determinar cuales partes de cada archivo son necesarias y
también decidir como se relacionaban los archivos entre si, para la coordinación del
procesamiento de los archivos de modo tal que se extraigan los datos correctos.
Coordinar dos archivos es muy difícil, imagine la tarea de coordinar diez o más de
ellos.
• Duplicidad de la información: Por la naturaleza de los archivos la duplicidad de
información estaba a la orden del día lo cual derivaba en datos duplicados que
desperdician en espacio de almacenamiento, esta duplicidad tiene que ver con la
integridad en la información.Un conjunto de datos tiene integridad si son
consistentes, si se ensamblan entre si. Con frecuencia, en los sistemas de
procesamiento de archivos se aprecia una pobre integridad de los datos. Por
ejemplo, si un cliente cambia su dirección o nombre, deben actualizarse todos los
archivos que contienen sus datos, el peligro reside en que todos los archivos

pudieran no actualizarse, causando discrepancias. Los problemas de integridad de

los datos son serios, si estos difieren producirían resultados inconsistentes.
• Dependencia del programa de aplicación: con el procesamiento de archivos, los
programas de aplicación dependen de los formatos del archivo, en los sistemas de
procesamiento de archivos los formatos físicos de los archivos y los registros son
parte del código de aplicación. El problema con esto es que cuando se hacen
cambios en los formatos de archivos, también deben modificarse los programas de
aplicación.
• Archivos incompatibles: Dos aplicaciones diferentes pueden ser desarrolladas en
lenguajes diferentes, lo que acarrea que el formato de los archivos sea diferente y
no pueden combinarse o compararse con facilidad, esto requerirá tiempo. Tales
problemas se acrecientan a mediada que aumenta el número de archivos a
combinar.
• Dificultad de representar los datos como los ve el usuario: esta dificultad surge
porque el procesamiento de archivos no se representan o procesan con sencillez las
relaciones entre los registros ya que un sistema de procesamiento de archivos no
puede determinar con rapidez como se relacionan dos o mas archivos.
Sistemas de procesamiento de base de datos

La tecnología de bases de datos se desarrollo para superar las limitaciones de sistemas de
procesamiento de archivos. Los programas de procesamiento de archivos acceden a los
archivos de los datos almacenados. En contaste, los programas de procesamiento de base
de datos acuden al Sistema Gestor de Base de Datos (DBMS) para acceder los datos
almacenados.
Esta diferencia es significativa: hace más fácil la tarea de programar la aplicación.

Los programadores no deben preocuparse por la forma en la que los datos se almacenan.
Mas bien quedan libres para concentrarse en cuestiones importantes para el usuario, y no
en aspectos de sistema de computación. Los sistemas de procesamiento de base de datos
tienen las siguientes características:
• Datos integrados: Es un sistema de base de datos todos los datos se almacena en

un medio común (base de datos). Un programa de aplicación puede ordenar al
DBMS que acceda a los datos de clientes, ventas o ambos, el programador de una
aplicación solo especifica como deberán combinarse los datos y el DBMS realiza
las operaciones necesarias para conseguirlo. El programador no es responsable de
escribir los programas para coordinar los archivos.
• Menos duplicación de datos: Siempre que el DBMS necesite datos puede traerlos
y solo es necesaria una autorización para modificarlos. Debido a que estos datos se
almacenan en un solo lugar, resultan menos comunes los problemas de integridad

de datos; hay menor oportunidad de discrepancia entre las múltiples copias de los
mismos elementos de datos.
• Independencia programa/datos: El procesamiento de base de datos hace que los
programas dependan menos de los formatos de archivo. Los formato de registro se
le almacenan en la misma base de datos y son accedido por el DBMS, no por los
programas de aplicación, esto minimiza el impacto de los cambios almacenados al
DBMS, que a su vez actualiza los datos y mantiene la relación con la estructura de
la base de datos.
• Fácil representación de la vista de datos: La tecnología de bases de datos hace
posible representar de un modo directo los objetos en el universo del usuario.
Definición de base de datos

Se ha hablado de los sistemas de procesamiento de base de datos, pero en si ¿qué es una
base datos?, para ello veremos las siguientes definiciones empezando por la más simple y
después analizando definiciones más complejas, para después ver sus características,
objetos, usuarios, entre otros.
• Una base de datos es una recopilación de información almacenada en forma

organizada.
• Una base de datos es un conjunto de archivos interrelacionados entre si para un fin
determinado.
• Una base de datos es un conjunto autodescriptivo de registros integrados.
¿Por qué autodescriptiva? Por que aparte de contener los datos fuente del usuario
contiene también una descripción de su propia estructura, tal descripción es conocida
como diccionario de datos o metadatos, lo que promueve la independencia entre el
programa y los datos ya que al cambiar la estructura de los datos en la base de datos solo
se introduce el cambio en el diccionario de datos.
¿Por qué es un conjunto de registros integrados? Por la jerarquía natural de los

datos, los bits conforman bytes o caracteres, los caracteres conforman campos, los
campos registros, y los registros componen archivos, si bien es posible deducir que los
archivos (datos del usuario, tablas, afinidades) conforman base de datos hay elementos
que la componen y hay que tomar en cuenta:
‣ Los metadatos, que es la descripción de la base de datos (tablas y columnas) Tablas:

Nombre, numero de columnas y clave primaria, etc. Columnas: Nombre, a que
tabla pertenece, tipo de dato, longitud, etc.
‣ Los índices, que se usan para representar las relaciones entre los datos y mejorar el
desempeño de las aplicaciones de la base de datos ya que se utilizan para ordenar

los datos y de esta manera tener un rápido acceso a los datos, son muy valiosos para
clasificación y búsqueda.
‣ Los metadatos de aplicación que se refieren a la información que la aplicación
utiliza, como lo son la estructura de las formas de entrada de datos, salida de datos
ya sean en pantalla o como reportes, etc.
• Una base de datos es un modelo de un modelo.
Es tentador decir que una base de datos es un modelo de la realidad o de alguna

parte de la realidad. Sin embargo, esto no es verdad, una base de datos no representa la
realidad o parte de esta, en cambio una base de datos es un modelo del modelo del
usuario, es un modelo de como cierta persona ve su negocio u organización ya que
contiene representaciones concernientes a información pertinente a la organización.
Las bases de datos varían en su nivel de detalle, el grado de detalle que debe
incorporarse en una base de datos depende de la información deseada. Es evidente que
entre más información se requiera la base de datos deberá poseer mas detalles, decidir la
cantidad apropiada de detalles es una parte importante del trabajo al diseñar una base de
datos. El criterio principal es el nivel de detalle que imagina el usuario.
Las organizaciones cambian, la gente va y viene, a medida que estos cambios

ocurren, también deben alterarse los datos que representan el negocio. De lo contrario, la
información se volverá obsoleta y representara la organización de un modo inadecuado.
A continuación se presentan un concepto de base de datos que abarca en gran parte

las anteriores definiciones:
• Una base de datos es una colección de archivos relacionados que almacenan tanto
una representación abstracta del dominio de un problema del mundo real cuyo
manejo resulta de interés para una organización, como los datos correspondientes a
la información acerca del mismo. Tanto la representación como los datos están
sujetos a una serie de restricciones, las cuales forman parte del dominio del
problema y cuya descripción esta también almacenada en esos archivos.
Objetivos de las bases de datos

Los principales objetivos de una base de datos se resumen a los siguientes puntos:
★ Organizar información.
★ Controlar información.
★ Presentar información de forma integra y rápida a los usuarios.

★ Evitar perdida de información de vital importancia para el usuario ya sea un

individuo u organización.
Para cumplir con estos objetivos independientemente de la arquitectura de la base

de datos, esta debe cumplir con una serie de características para ser considerada como tal,
algunas de las cuales se describirán a continuación:
• Versatilidad para la representación de la información: Si bien la información

que forma parte del dominio de un problema es única y caracteriza a ese problema,
pueden existir diferentes visiones de esa información. La organización de la
información en la base de datos debe permitir que diferentes procedimientos puedan
construir diferentes registros a partir de la información existente en la base de datos.
• Desempeño: Las bases de datos deben asegurar un tiempo de respuesta adecuado en
la comunicación hombre-maquina, permitiendo el acceso simultáneo al mismo o
distinto conjunto de elementos de datos por el mismo o distinto procedimiento.
• Mínima redundancia: La existencia de redundancia es nefasta debido a la
posibilidad de inconsistencia en la información almacenada en la base de datos, la
redundancia implica la existencia de varias copias de un mismo elemento de datos,
los cuales pueden tener distintos valores, por ello las bases de datos tienen como
principal objetivo eliminar redundancia siempre y cuando no implique una
complejidad de la misma o una disminución en el desempeño.
• Capacidad de acceso: Los usuarios de la base de datos reclaman a esta
continuamente información sobre los datos almacenados por lo que una base de
datos debe ser capaz de responder, en un tiempo aceptable, a cualquier consulta
sobre la información que mantiene; esta característica va a depender directamente de
la organización física de los datos en la base de datos.
• Simplicidad: Las bases de datos deben estar basadas en representaciones lógicas
simples que permitan la verificación en la representación del problema que
representan y, mas aun, modificación de nuevos elementos de datos y relaciones no
ocasione una complejidad excesiva.
• Integridad: Este aspecto de la base de datos hace referencia a la veracidad de los
datos almacenados con respecto a la información existente en el dominio del
problema que trata la misma. Como los datos de las base de datos con manejados
por muchos usuarios haciendo uso de muchos procedimientos que tratan los mismos
datos de muchas formas, es necesario garantizar que estos datos no sean destruidos
ni modificados de forma anómala, a través procedimientos de verificación que se
ajusten a requisitos y restricciones extraídas del análisis del problema.
• Seguridad y privacidad: La seguridad de una base de datos hace referencia la
capacidad de esta para proteger a los datos contra su pérdida total o parcial por
fallos del sistema o por accesos accidentales o intencionados a los mismos. Mientras
que la privacidad de una base de datos hace referencia a la reserva de la información
de la misma a personas no autorizadas. La información de la base de datos es de

vital importancia y valor para la organización responsable de la misma. A medida

que esta información es mas importante, tanto mas valioso se hace para la empresa
al mantener su seguridad y privacidad.
Modelos de datos
El diseño de base de datos se concentra en la forma en que la estructura de base de datos
se usará para guardar y administrar datos del usuario final. El modelado de datos, primer
paso para diseñar una base de datos, se refiere al proceso de crear un modelo especifico
de datos para el dominio de un problema determinado. Un modelo es una representación
relativamente sencilla, por lo general gráfica, de estructuras de datos reales más
complejas.
En términos generales, un modelo es una abstracción de un objeto o hecho real

más complejo. La función principal de un modelo es ayudar a que el lector entienda las
complejidades del ambiente real. Dentro del ambiente de una base de datos, el modelo
representa estructuras de datos y sus características, relaciones, restricciones,
transformaciones y otras construcciones con el propósito de sostener un dominio de
problema específico.
El modelado de datos es un proceso iterativo y progresivo. Se empieza con una

comprensión sencilla del dominio, del problema y a medida que aumente ésta, también se
incrementa el nivel de detalle del modelo de datos. Si se hace en una forma apropiada, el
modelo de datos final es en efecto un “plano” que contiene todas las instrucciones para
construir una base de datos que va a satisfacer todas las necesidades del usuario final.
Este plano es narrativo y gráfico en su naturaleza, lo cual significa que contiene

descripciones de texto en lenguaje sencillo, no ambiguo y claro, que describe los
elementos principales de los datos.
Un modelo de datos listo para la implementación debe contener al menos los

siguientes componentes:
• Una descripción de la estructura de datos que guardara los datos del usuario final.
• Un conjunto de reglas que se pueden hacer cumplir para garantizar la integridad de
los datos.
• Una metodología de manipulación de datos para apoyar las transformaciones de los
datos reales.
Los modelos de datos pueden facilitar la interacción entre el diseñador, el

programador de aplicaciones y el usuario final. Un modelo bien diseñado puede incluso

promover un mejor entendimiento de la organización para la cual se desarrolló el diseño

de la base de datos.
Los datos constituyen las unidades de información mas elementales que un sistema
emplea. Las aplicaciones son creadas para manejar datos y ayudar en transformarlos en
información. Pero los datos son visos en distintas formas por diferentes personas. Los
diferentes usuarios y productores de datos e información a veces reflejan la analogía de la
persona ciega y el elefante, la persona ciega que sintió la trompa tiene una visión muy
diferente con respecto a quien siento la pata o la cola.
Cuando se dispone de un buen plano de la base da datos, no importa que la vista

que el programador de aplicaciones tenga de los datos sea diferente a la de un gerente o
usuario final. El modelo de datos es una abstracción. Así como es probable no construir
una buena casa sin ninguna plano, es igualmente improbable crea una buena base de datos
sin elaborar un modelo apropiado de datos.
Los elementos básicos de un modelo de datos son: entidades, atributos, relaciones

y restricciones; estos elementos se describirán mejor en la unidad 2 de la asignatura. Estos
elementos sin embargo podrían no tener sentido sin las reglas de negocio. Una regla de
negocio es una descripción breve, precisa y no cambia de una política, procedimiento o
principio dentro de una organización especifica. En cierto sentido, las reglas de negocio
tienen un nombre erróneo, ya que se pueden aplicar a cualquier organización grande o
pequeña: un negocio, una unidad de gobierno, un grupo religioso, un laboratorio de
investigación, entre otras, que guarde y utilice datos para generar información.
Abstracción de la información
Para que una base de datos pueda satisfacer las características y objetivos antes señalados,
y otras más, es necesario que los usuarios de la misma tengan una visión abstracta de los
datos almacenados. Dependiendo de quien acceda o use la base de datos, esta debe
presentarle una visión de los datos que sea capaz de reconocer, interpretar y manejar; por
lo que se puede hablar de tres visiones de los datos de una base de datos:
• Visión externa: es la visión de los datos que tienen los usuarios finales de una base
de datos. Un usuario trata solo una visión parcial de la información, solo aquella que
intervienen en el dominio de actividad. Este usuario debe ver la información que
maneja como un registro independiente que los elementos de datos tengan su origen
en diferentes archivos. Por otro lado, otro usuario vera también su registro particular
de información cuyos elementos podrán ser comunes o no, al de otros registros
particulares de otros usuarios.

• Visión conceptual: Es la visión del problema tal y como éste se presenta en el

mundo real. Una base de datos representa la información que es observada en el
mundo real con respecto a un determinado problema. En esta observación, en el
análisis del problema, se determinan los objetos, propiedades y relaciones entre
ellos. De esta manera la visión conceptual de una base de datos no cambia a no ser
que cambie la naturaleza del problema.
• Visión física: es la representación de como la información es almacenada en los
dispositivos de almacenamiento. Esta visión describe las organizaciones físicas,
dispositivos, volúmenes, archivos, tipos de datos, punteros, etc., estructuras de
mayor a menor complejidad que representan el dominio del problema de una forma
entendible por el sistema informático.
Arquitectura de un sistema gestor de base datos

Es importante conocer la diferencia entre lo que es una base de datos y lo que es un
sistema gestor de base de datos, términos que confunden muy a menudo cuando se esta
trabajando con la información haciendo uso de esta tecnología.
Hasta estos momentos se ha estado tratando únicamente el termino de base de

datos, aportando una definición, cuando se habla de bases de datos se habla de
información que esta almacenada cumpliendo toda una serie de características y
restricciones como las que se han expuesto.
Pero para que la información deba estar almacenada como se ha descrito y el

acceso a la misma satisfaga las características exigidas a una base de datos para ser
denominada como tal, es necesario que exista una serie de procedimientos(un sistema de
software) que sea capaz de llevar a cabo tal labor. A este sistema de software es a lo que
se le denomina sistema de gestión de base de datos (DBMS. Por sus siglas en inglés Data
Base Management System).
Así, un DBMS es una colección de programas de aplicación que proporcionan al

usuario de la base de datos los medios necesarios para realizar las siguientes tareas:
• Definición de los datos a los distintos niveles de abstracción(físico, lógico, y

externo)
• Manipulación de los datos en la base de datos. Es decir, la inserción, modificación,
borrado y acceso o consulta a los mismos.
• Mantenimiento de la integridad de la base datos. Integridad en cuanto a los datos en
si, sus valores y las relaciones entre ellos.
• Control de la privacidad y seguridad en las bases de datos.

• Y, en definitiva, los medio necesarios para el establecimiento de todas aquellas

características exigibles a una base de datos.
Un componente importante del DBMS es el gestor de la base de datos conocido

como motor DBMS o monitor, que es el encargado de garantizar el correcto, seguro,
integro y eficiente acceso y almacenamiento de los datos, es el encargado de proporcionar
la interfaz entre el conjunto de datos y el usuario. Toda operación que se requiera realizar
contra la base de datos debe ser previamente permitida por el gestor de la misma, el cual,
una vez interpretada y validada, o bien realiza la operación devolviendo el resultado de la
misma al programa/procedimiento que la solicito, o bien la rechaza.
De esta manera, el gestor de la base de datos es responsable de garantizar la

privacidad, seguridad, integridad de la base de datos, garantizar el acceso concurrente a la
base de datos e interactuar con el sistema de operativo mediante el procesador de
consultas particularmente con el administrador de archivos.
Tipos de lenguajes
Para realizar todas las funciones del DBMS, es necesario que cuentan con un componente
que permita la realización de esta tarea. El lenguaje de definición de datos — Data
Definition Language (DDL) — es un lenguaje basado en un determinado modelo de datos
que permite la representación lógica de los datos.
Generalmente, los DDL de los diferentes DBMS son los lenguajes simples basados
en una gramática sencilla que cuenta con un conjunto muy reducido de morfemas, lo que
garantiza la definición no ambigua de los datos. Esta definición debe ser compilada para
dar lugar a una representación orientada a la maquina que es la que utiliza el DBMS en
tiempo de procesamiento.
La representación de los datos obtenida en el proceso de compilación es

almacenada en otro componente denominado Diccionario de Datos.
El DDL permite describir los elementos de datos, su estructura, sus interrelaciones

y la validación de la base de datos, y subdivide en:
• Lenguaje de definición del almacenamiento de datos: DSDL (Data Storage

Definition Language) es el que define los datos correspondientes la dominio de un
programa a los dos niveles de abstracción, y a esta definición delos datos se le
denomina Esquema de Base de Datos.
• Lenguaje de control de datos: DCL (Data Control Language) permite el control del
acceso a la información almacenada en el diccionario de datos.

Otro componente de los DBMS es el DML mediante el cual se realizan dos

funciones bien diferentes en la gestión de los datos:
• La definición del nivel externo o de usuario de los datos.

• La manipulación de los datos; es decir, la inserción, borrado, modificación y
recuperación de los datos almacenados en la base de datos.
Al igual que el DDL, el DML esta basado en un modelo de datos y, por tanto, los
DBMS basados en distintos modelos de datos tienen diferentes DML. Se trata también de
un lenguaje basado en una gramática completa, sencilla y, generalmente, fácil de entender
por los usuarios no expertos.
Dependiendo del modo de datos en el cual se soportan y, por supuesto, del DBMS,
existen dos tipos de DML:
• Procedimentales: los cuales requieren que en las sentencias de lenguaje se

especifique que datos se van a manipular, que se desea obtener y que acciones u
operaciones deben realizarse para ello.
• No procedimentales: los cuales solo requieren que en las sentencias del lenguaje se
especifique que datos se van a manipular y que se desea obtener, asiendo el propio
DML el encargado de determinar los procedimientos mas efectivos para ello.
Tipos de usuarios
Administrador de la Base de Datos
Uno de los componentes de los DBMS es del administrador de la base de datos – Data
Base Administration (DBA) –. Se trata de un componente humano de suma importancia
en el uso de la base de datos va atener en la resolución de determinado problema, este
tiene una serie de responsabilidades en cuanto a la definición, administración, seguridad,
privacidad e integridad de la información que es tratada, así como en el desempeño del
DBMS en el procesamiento de la misma. Entre las tareas asignadas al DBA se
encuentran:
• La definición del esquema lógico de la base de datos. Es decir, la codificación

mediante sentencias del DDL del conjunto de definiciones que representan las
características del problema que se va hacer tratado haciendo uso del DBMS. En
esta definición se incluyen aquellas especificaciones necesarias para que el DBMS
pueda mantener la integridad de los datos almacenados en la base de datos.

• La definición del esquema físico de la base de datos. Es decir, la especificación de

las estructuras de almacenamiento y los métodos de acceso a la información
almacenada en los dispositivos físicos de almacenamiento. Esta definición se
almacena haciendo uso del DSDL o el DDL mediante un conjunto de sentencias que
son compiladas y traducidas a una especificación entendible por la maquina y que es
almacenada en el diccionario de datos junto con el esquema lógico.
• La definición de las visiones externas de la base de datos. Aquellas vistas parciales
• de la base de datos que son almacenadas por el diccionario de datos son definidos
por el DBA, el cual es el único que tiene acceso y, por tanto, privilegios suficientes
para la gestión de este componente.
• El control de la privacidad de los datos, mediante la concesión de privilegios a
usuarios o grupos de estos para el acceso a la información almacenada en la base de
datos. Esta tarea se realiza en base al esquema de la base de datos y en base a las
operaciones básicas que pueden realizarse con los datos, concediéndose privilegios
para una o varias de estas acciones a grupos de datos definidos en el esquema de la
base de datos.
• Mantenimiento de los esquemas. Así , el DBA es el responsable de:
- Introducir las modificaciones necesarias al esquema lógico; modificaciones

producidas por un cambio en el problema tratado por el DBMS o una
ampliación del mismo.
- Introducir las modificaciones necesarias en la representación física de los
datos, de forma que esta representación evolucione paralelamente a la
extensión de la base de datos y a la introducción de nuevos requisitos
funcionales y/o de desempeño.
- Introducir las modificaciones y nuevas definiciones de las visiones externas,
aportando una explotación efectiva de la base de datos.
• La especificación de los procedimientos necesarios para el mantenimiento de la

seguridad de los datos almacenados en la base de datos. Es decir, cuando, como, y
de que forma se deben realizar y definir los procesos que garanticen que los datos
puedan ser recuperados aun después de un fallo de que lugar a una perdida temporal
de los mismos.
Usuarios de las Base Datos

Tradicionalmente se ha considerado a los usuarios de la base de datos como un
componente más de los DBMS, posiblemente debido a que estos sistemas fueron los
primeros en considerar a estos como una parte importante del correcto, adecuado y
necesario funcionamiento de los mismos.

Naturalmente, en un sistema de esta complejidad existen muchos tipos de usuarios

que acceden e interactúan con el mismo, así se pueden considerar:
• Usuarios terminales: aquellos que a través de programas de aplicación interactúan

con la base de datos. Son los usuarios no especializados que tienen la visión del
problema que les proporcionan las visiones externas que utilizan los programas de
aplicación a los cuales tienen privilegios de ejecución.
• Usuarios técnicos: aquellos que desarrollan los programas de aplicación que van a
ser utilizados por los usuarios terminales de la base de datos. Son profesionales
informáticos que, haciendo uso de los lenguajes de programación, preparan
procedimientos que son invocados desde una interfaz orientada al usuario para
realizar las operaciones necesarias para en la gestión del problema.
• Usuarios especializados: aquellos que utilizan el DBMS como una herramienta en
el desarrollo de otros sistemas más o menos complejos. Estos usuarios necesitan una
buena gestión de la información que es procesada por otros sistemas comercial o
desarrollo por ellos y, por tanto, utilizan el DBMS con un submódulo de sus
sistemas particulares, interactuando con el en la medida que le es necesario.
• Usuarios críticos: estos usuarios pueden tener desde mucho, hasta ningún
conocimiento técnico de la tecnología de la base de datos, y/o el DBMS en el cual
se soporta la base de datos con la cual interactúan pero, independientemente de ello,
requieren de la base de datos información de un formato, detalle y bajo unos
requisitos que generalmente no están previstos de antemano y en un tiempo mínimo.
Se trata de aquellos usuarios gerenciales o pertenecientes al staff de las empresas en
las cuales se ha instalado la base de datos, los cuales, en base a las expectativas de
gestión, administración, mercado, marketing o simplemente por interés personal,
realizan consultas no previstas sobre la información almacenada en la base de datos.
Estructura general del sistema

Una aplicación de la base de datos consta de formas, consultas, reportes, menús, y
programas de aplicación. Las formas, consultas y reportes se definen usando herramientas
suministradas con el DBMS. Los programas deben escribirse en un lenguaje que sea
parte del DBMS o en lenguaje estandarizado y conectado a la base de datos a través del
DBMS.
• Formas: son los formularios que contienen elementos gráficas (cajas de texto,
etiquetas, casillas de verificación, entre otras) que permiten ingresar datos al
sistema.
• Consultas: De vez en cuando los usuarios desean consultar los datos para contestar
preguntas o para identificar problemas o situaciones particulares, para ello puede
usarse el lenguaje SQL de acceso a datos o utilizar una herramienta del DBMS

• Reportes: Un reporte es una representación que tiene un formato de la información

de una base de datos. Desarrollar un reporte es similar a preparar una forma para
ingresar datos, aunque en ocasiones es más fácil, ya que puede concebirse para que
solo se escriba. Otras veces es más difícil desarrollar reportes, dado que con
frecuencia tienen una estructura mas complicadas que las formas.
• Menús Los menús se usan para organizar los componentes de la aplicación con el
propósito de que el usuario final acceda a ellos con facilidad, el acceso puede a ser a
través de botones o listas despegables.
• Programas de aplicación: El componente final de una aplicación de base de datos
es el programa de aplicación. Como se menciono antes, tales programas pueden
escribirse en un lenguaje especifico para el DBMS o en un lenguaje estándar que
produce una interfaz con el DBMS, a través de una interfaz predefinida del
programa.

UNIDAD 2
DISEÑO DE BASE DE DATOS Y

MODELO ENTIDAD RELACIÓN
• Analizar y aplicar el modelo E-R para el diseño conceptual de bases de datos y los
posibles tipos de asociaciones entre tablas y su instrumentación.

Diseño de Base de Datos

En base de datos llamaremos modelo M al instrumento que se aplica al mundo real
(información) para obtener una estructura de datos a la cual denominamos esquema. Para
definir un modelo se emplean:
• La estática, representa las estructuras: (S) DDL

• La dinámica, representan las operaciones o manipulaciones de las estructuras en el
transcurso del tiempo: (D) DML
M=<S, D>
Un esquema de base de datos es un diseño a partir del cual se desarrollan la base

de datos y las aplicaciones, define la estructura de la base de datos: sus tablas, relaciones,
dominios y reglas de negocio. Para ilustrar un esquema y su importancia, considere el
siguiente ejemplo, una universidad que tiene actividades extraescolares y mantiene un
registro de los artículos deportivos que han sido prestados a los capitanes de los equipos.
Tablas: Captain (CapID, Name, Phone, Street, City, State, Zip)

Item (ItemID, Quantity, Description, DateOut, DateOut, DateIn, CapID)
Relación: La relación entre las dos tablas es como sigue, una fila de Captain se
relaciona con muchas filas de Item pero una fila de Item se relaciona con solo una de
Captain. Mas adelante se abordara a detalle el tema de las relaciones.
Dominio: es una serie de valores que pueden tener una columna, se debe
especificar un dominio para cada columna de cada tabla y que dominios será únicos para
la tabla, por ejemplo: ItemID, Quantity, CapID tienen valores de números entero;
Description tiene valores de caracteres y DateOut, DateIn tienen valores de fecha
Reglas de negocio: son restricciones en las actividades de la organización que

necesitan reflejarse en la base de datos y sus aplicaciones. Un ejemplo para este caso
puede ser que para pedir prestado cualquier equipo deportivo, un capitán debe tener un
número de teléfono local. Las reglas de negocio son parte importante del esquema porque
especifican limitaciones sobre los valores de datos permitidos que deben cumplirse, sin
importar la forma en que los cambios en los datos llegan al motor DBMS. Los actuales
productos DBMS solo ofrecen un cumplimiento limitado de las reglas de negocios, de
modo que la mayor parte de las reglas deben cumplirse mediante programas de aplicación
y procedimientos llevados acabo por el usuario.

Modelo Entidad - Relación

El modelado conceptual de datos, crea una representación de la visión que tienen los
usuarios de los datos presentes en el sistema. Si el modelo de datos representa de manera
incorrecta esta visión, las aplicaciones serán difíciles de usar, incompletas y frustrantes.
El modelo Entidad - Relación (E-R) fue introducido por Peter Chen en 1976 con
el objetivo de incorporar información semántica importante lo que proveía a diferencia de
otros modelos en esos años una gran independencia de datos, el modelo se basa en dos
teorías: la relacional y la de conjuntos; desde esa fecha hasta entonces este modelo ha
sido ampliado y modificado.
La definición según Chen: “El modelo E-R puede ser usado como una base para
vistas unificadas de datos, adoptando el enfoque mas natural de lo real, que consiste en
entidades y relaciones”.
El objetivo de este modelo es la representación conceptual de los problemas y

representar una visión de los mismos de manera global; se emplea para interpretar,
especificar y documentar los requerimientos para sistemas de procesamiento de bases de
datos, ya que proporcionan estructuras que muestran el diseño de base de datos de lo
general a lo particular.
El modelo E-R se ha incorporado a varias herramientas CASE, las cuales también

lo han modificado. En la actualidad no hay un solo modelo estandarizado E-R. Por lo
contrario, hay un conjunto de estructuras comunes, a partir de las cuales se conforman la
mayoría de las variantes E-R.
Este modelo permite la representación de cualquier tipo de sistema a cualquier tipo

de nivel de abstracción o refinamiento. La representación de los datos se realiza mediante
un conjunto de símbolos y un reducido conjunto de reglas que representan los elementos
del sistema y sus relaciones. Para llegar a esa representación se deben identificar las
entidades (elementos) y sus propiedades y como estas entidades se relacionan.
Entidades
Una entidad es un objeto real o abstracto acerca del cual se puede almacenar información;
es algo que puede identificarse en el ambiente de trabajo de los usuarios, algo importante
para los usuarios del sistema que se va a desarrollar.
Estrictamente hablando es un conjunto definido en base a la agregación de

atributos o propiedades que describen a la entidad, al menos uno de los atributos debe

identificar de manera única a cada ocurrencia de la entidad, a este atributo se le conoce

como identificador o clave. De aquí se desprenden dos conceptos:
• Intención: también denominada tipo de entidad, representa el posible conjunto de

atributos, en términos de abstracción representa la clasificación de las entidades
individuales.
• Extensión: es denominada conjunto de entidades, y se corresponde con todos los
valores que en un momento dado están asociados con un atributo que define el tipo
de entidad.
Por ejemplo, el tipo de entidad Persona, puede ser definida en base a la

agregación de atributos tales como: <nombre, edad, ciudad, estado-civil>, cada uno de
estos atributos tienen un dominio; la extensión del tipo de entidad Persona corresponde
con todas las personas existentes en un momento dado, por ejemplo <José, 28, Madrid,
casado>, <Antonio, 34, Lugo, soltero>, etc. Toda entidad debe cumplir con las siguientes
propiedades:
• Tiene existencia propia, es decir, desde el punto de vista en el cual se estudia el

sistema y al nivel de abstracción en el cual es considerado, la entidad existe como
un elemento que interviene en el comportamiento global del sistema.
• Es distinguible del resto de las entidades que intervienen en el sistema.
• Las entidades del mismo tipo están definidas en base a un mismo conjunto de
atributos, cada una de ellos definido en un mismo dominio; en otras palabras todas
las ocurrencias de un tipo de entidad deberá tener las mismas características.
Existen entidades fuertes, débiles por identificación y débiles por existencia.

También se pueden identificar especializaciones de entidades:
• Tipo de entidades fuertes o entidades regulares: cuya existencia no depende de la

existencia de ningún otro tipo de entidad en la consideración del problema, aquellas
que tienen existencia propia, se representan mediante un rectángulo y el nombre del
tipo de entidad regular en mayúsculas.
ENTIDAD FUERTE
• Tipo de entidades débiles: cuya existencia depende de la existencia de un tipo de

entidad fuerte, se representan mediante un rectángulo con esquinas redondeadas y el
nombre de entidad débil en minúsculas.
Entidad Débil

Los atributos describen las características de una entidad, es definido en función

de un dominio y el conjunto de posibles valores que pueden ser medidos para ese
atributo. Por ejemplo, en el atributo edad considerado en un determinado problema en el
que se trate la edad de una serie de personas, puede ser definido sobre la base del de los
números enteros de dos cifras, se representan gráficamente por eclipse o circulo.
Nombre
Dirección
PERSONA
Edad
Telefono
Relaciones
Las relaciones son asociaciones entre dos o más entidades, desde el punto de vista de
teoría de conjuntos es una correspondencia entre conjuntos, pueden tener o no atributos, y
tiene un nombre único;existen dos tipos de relaciones:
• Regulares: estas se dan entre entidades regulares únicamente, se representan por un

rombo.
• Débiles: se dan entre entidades regulares y débiles o solo entre débiles, se

representan como un rombo con esquinas redondeadas. Las entidades débiles
pueden ser de dos tipos:
- Debilidad por identificación: por lo que la entidad débil no puede ser
identificada (reconocida y diferenciada del resto de las entidades del mismo u
otro tipo) a no ser que se identifique una entidad fuerte por cuya existencia esta
presente la debilidad.
- Debilidad por existencia: por lo que una entidad débil puede ser identificada
sin necesidad de identificar la entidad fuerte por la cual existe.

Dependiendo de la cantidad de entidades que intervienen en la relación se pueden

tener relaciones binarias, ternarias o n-arias; la cantidad de entidades en una relación es
conocida como grado de la relación, comúnmente se tienen relaciones binarias. Las
relaciones tienen una correspondencia que es la cantidad de ocurrencias de una entidad en
cada tipo de entidad que intervienen en una relación, a lo cual se le conoce como
cardinalidad, estas ocurrencias pueden ser de uno a uno (1:1), de uno a muchos (1:N) y
de muchos a muchos (N:M) y se conocen como cardinalidad máxima y se expresa
dentro del rombo, también las relaciones tienen cardinalidad mínima la cual se
representa con una barra que representa que pude existir un solo elemento o un circulo
que representa que puede existir o no un elemento. Las relaciones tienen un rol, que no es
más que la función que desempeña cada entidad en la relación.
PEDIDO - VENDEDOR
VENDEDOR PEDIDO
a) Relación binaria (grado 2)

llamada Pedido-Vendedor
PADRES
MADRE PADRE
HIJOS
b) Relación grado 3 llamada

Padres
ESCRIBIR
Escribe » « Escrito por

AUTOR LIBRO
:M
N
c) Relación binaria llamada

Escribir, que tiene roles:
Escribe y Escrito por.
Las cardinalidades máximas cobran importancia cuando se hable del modelo

relacional el cual se tratará en la siguiente unidad de aprendizaje, a continuación se
detallan tres tipos de relaciones binarias con su ejemplos:

• De uno a uno (1:1): una entidad única de un tipo de entidad se relaciona solo con
una entidad única de otro tipo de entidad.
AUTO - ASIGNACION
EMPLEADO AUTO
1
1:
• De uno a muchos (1:N): una entidad única de un tipo de entidad se relaciona con
muchas entidades de otro tipo de entidad.
DORMITORIO - OCUPANTE
DORMITORIO ESTUDIANTE
N
1:
• De muchos a muchos (N:M): varias entidades de un tipo de entidad se relaciona

con muchas entidades de otro tipo de entidad.
ESTUDIANTE - CLUB
ESTUDIANTE CLUB
:M
N
Diagrama Entidad-Relación DER

Tenemos entonces que un diagrama entidad relación es un herramienta para el modelo de
datos, que permite representar las entidades relevantes de un sistema así como sus
relaciones y propiedades. El diagrama se construye de una forma iterativa siguiendo los
pasos a continuación enumerados:
1. Durante la recopilación de requisitos se pide al cliente liste las “cosas” que afronta
el proceso de la aplicación y/o del negocio. Estas cosas evolucionan en una lista de
objetos de datos de entrada y salida así como entidades externas que producen y
consumen información.

2. Tomando una entidad a la vez el analista y el cliente define si existe conexión o no

entere esa entidad y otras.
3. Siempre que existe una conexión, el analista y el cliente crean una o varias parejas
Entidad – Relación.
4. Para cada E-R se explora su cardinalidad máxima y mínima.
5. Se continúan los pasos del 2 al 4 hasta que se haya definido todas las parejas E-R.
Es natural descubrir omisiones a medida que el proceso continua, entidades y
relaciones nuevas se añadirán invariablemente a medida y crezca el número de
interacciones.
6. Se definen los atributos de cada entidad y de cada relación.
7. Se formaliza y se revisa el diagrama E-R.
8. Se repiten los pasos del 1 al 7 hasta que se termina el modelado de datos según el
nivel de detalle que se desee.
De esta manera se pueden obtener diagramas entidad - relación como el que sigue:
DORMITORIO ESTUDIANTE
N
1:
Ubicación NoControl
CantHabitantes Renta Nombre
NoDormitorio Semestre
Modelo Entidad-Relación Extendido (EE-R)

El modelo E-R permite la representación de cualquier tipo de relación existente entre los
objetos del mundo real que forman parte del dominio del problema en estudio. Las
últimas actualizaciones del modelo E-R, que han dado lugar a lo que se denomina modelo
entidad relación extendido (EE-R), permiten la representación de cualquier tipo de
relaciones existentes entre clases de objetos que consideren los principios de la
abstracción.
La generalización es la abstracción por la cual un conjunto de clases de objetos

pueden ser vistas como una nueva clase de objetos más general, la generalización de
objetos más simple en una clase es denominada clasificación, y se les denomina
especialización e instanciación a los procesos inversos a la generalización y clasificación.
La agregación, por otra parte, es la capacidad de considerar un objeto basándose

en los elementos que lo constituyen o como un conjunto de propiedades que lo

caracterizan y que lo diferencian de otra clase. El proceso inverso a la agregación se

denomina refinamiento, mediante el cual se puede representar a aquellos objetos simples
o propiedades que caracterizan a una clase de objetos.
La generalización puede asociarse con el concepto ES_UN, ya que mediante esta

abstracción es posible representar a aquellos objetos o clases de objetos que pertenecen o
pueden ser considerados como un tipo o clase de objetos más general. Pero por otro lado,
la agregación puede asociarse con el concepto PARTE_DE, puesto que mediante esta
abstracción puede representarse que un objeto o clase de objetos está formado por una
serie de objetos o clases constituyentes que lo caracterizan como objeto a clase.
Relaciones Reflexivas
También denominadas relaciones recursivas, son relacionesunarias y, por tanto,
consideren que en el tipo de relación se involucra un único tipo de entidad. Por ejemplo:
consideremos el tipo de relación presentado en la siguiente figura:
Es_jefe_de »
TRABAJADOR
N
1:
Es_subordinado_de »
Aquí se muestra la relación existente entre el tipo de entidad Trabajador con ella
misma, y representa que un trabajador es jefe de 0 a varios trabajadores, mientras que un
trabajador solo es dirigido por 0 (el jefe de todos) o 1 un trabajador.
Se trata de un tipo de relación reflexiva en la que interviene un único tipo de

entidad que desempeña dos papeles diferentes en el mismo tipo de relación. No todos los
modelos de datos permiten representar ese tipo de relaciones, tal y como se representan
en el mundo real. Hay que tener en cuenta que no siempre será fácil la traslación de esta
representación conceptual a una representación lógica.
Relaciones Exclusivas
En un problema del mundo real, un tipo de entidad puede mantener relaciones con un
conjunto con otros tipos de entidad, pero no siempre estas relaciones son independientes.
Consideremos el ejemplo que se muestra en la siguiente figura:

PROVEEDOR
:1
N
ARTICULO
FABRICANTE
:1
N
Se presentan tres tipos de entidad Articulo, Proveedor y Fabricante, el problema
radica en que los artículos son suministrados por los proveedores o por los fabricantes,
pero un articulo nunca puede ser suministrado por un proveedor que no fabrica el articulo,
de forma que si el fabricante puede suministrarlo, en ningún momento será solicitado ese
articulo a ningún proveedor.
Para indicar la exclusividad entre dos tipos de relación que mantiene el mismo la
misma entidad se procede a representar un segmento que corta a los dos que representan
la relación del tipo de entidad con los tipos de interrelaciones exclusivas. En otras
palabras se dice que dos o más tipos de relación son exclusivas cuando cada ocurrencia de
un tipo de entidad puede pertenecer a un tipo de relación.
Generalización en el modelo EER

El modelo EE-R permite representar las relaciones jerárquicas existentes de los tipos de
entidad de los problemas del mundo real. Como se ha descrito la generalización es una
abstracción que identifica una relación como jerárquica que representa un tipo de entidad
ES_UN subtipo de otro tipo de entidad que mantiene un tipo de relación jerárquica con
otro tipo de entidad, y que:
• Representa a un conjunto de entidades cuyas propiedades y comportamiento general
es considerado por el tipo de entidad con la que mantiene el tipo de relación.
• La relación jerárquica puede ser n-aria entre un tipo de entidad y un conjunto de
subtipos de este tipo de entidad.
• Las propiedades y e comportamiento de los subtipos heredados del tipo de entidad
con la cual mantienen in tipo de relación jerárquico. La herencia es una
consideración de que con una única definición de las propiedades y comportamiento
de un conjunto de entidades, esta definición es automáticamente considerada para
todos aquellos conjuntos con los que exista una relación jerárquica (una
especialización).
• Bien las propiedades y/o bien el comportamiento de un subtipo pueden y deben
cambiar con respecto a otros subtipos que intervengan en la misma relación
jerárquica n-aria entre todos los subtipos y un mismo tipo de entidad. Puesto que los
subtipos son tipos de entidad a un nivel de abstracción menor, estos deben poder

distinguirse sin ambigüedad del resto de los tipos de entidades existentes en la

representación del problema, por lo tanto, deben tener un conjunto de propiedades
que permitan esta discriminación.
• Para cada subtipo de entidad pueden redefinidas tanto las propiedades como el
comportamiento del tipo de entidad con la entidad con la que mantienen un tipo de
interrelación jerárquica. Esta característica permite la existencia de los mecanismos
para diferencias a los diferentes subtipos de una misma clase y, además, permite la
cancelación condicionada de la herencia producida por la relación jerárquica.
• Un tipo de entidad puede ser un subtipo para más de un tipo de entidad con las que
puede mantener diferentes relaciones jerárquicas. Esta característica, denominada
herencia múltiple, permite que un tipo de entidad herede propiedades y
comportamiento de más de otro tipo de entidad. La herencia múltiple puede dar
lugar, en ocasiones, inconsistentes en las propiedades y comportamiento de más de
un tipo de entidad, la herencia múltiple puede dar lugar, en ocasiones, a
inconsistencias de las propiedades y/o comportamiento que se hereda, lo que se debe
solucionar mediante la redefinición de las herencias.
Un tipo de interrelación jerárquica representa una especialización de un tipo de

entidad en otros tipos de entidad, esta especialización debe puede ser debida a:
1. La diferencia en cuanto al número de propiedades que definen los subtipos de

entidad. De esta forma, diferentes subtipos que mantienen un mismo tipo de
interrelación jerárquica son definidos sobre la base de la agregación de un conjunto
diferente de propiedades, si bien entre el conjunto de subtipos puede existir un
subconjunto de entidades comunes.
2. Diferentes valores que pueden ser medidos para una propiedad que existe en el
conjunto de subtipos que mantienen un mismo tipo de interrelación jerárquica
3. Que se cumplan ambas condiciones.
La especialización de un tipo de entidad en un subtipo de conjuntos puede ser

exclusiva o inclusiva. Una especialización exclusiva, denominada especialización sin
solapamiento, representa el hecho de que una instancia del tipo de entidad más general
solo puede pertenecer o estar asociada a una y solo una instancia de los subtipos de
entidad especializados.
Una especialización inclusiva, denominada especialización con solapamiento,

representa l hecho de que una instancia del tipo de entidad más general puede tener
asociadas instancias de cualquiera de los subtipos.
Por otro lado, la especialización de un tipo de entidad en un conjunto de subtipos

puede ser total o parcial. Una especialización total representa el hecho de que las
entidades que son reconocidas en el problema que se esta representando son de alguno de

los subtipos especializados, no existiendo entidades que no pertenezcan a alguno, varios o

todos estos subtipos de entidad. Una especialización parcial representa el hecho de que
pueden existir entidades que pertenezcan al tipo de entidad y no a ninguno de los subtipos
en los cuales este tipo de entidad está especializado. Una especialización parcial describe
el refinamiento incompleto del problema que se representa debido a un conocimiento
incompleto del mismo y/o una simplificación de la representación del mismo.
Para representar estos elementos en los diagramas entidad - relación extendidos se

emplean los siguientes símbolos:
Generalización, ES_UN.
Se presencia representa totailidad, su ausencia representa parcialidad.

Su presencia representa exclusividad, su ausencia representa inclusividad.
Por lo tanto se pueden presentar cuatro tipos de interpelaciones jerárquicas que se

representarán mediante el modelo EER: total sin solapamiento, parcial sin solapamiento,
total con solapamiento y parcial con solapamiento como se muestra en los siguientes
ejemplos.
Total sin solapamiento
Consideremos el tipo de entidad Persona, la cual puede ser especializada en dos subtipos
de entidad Hombre y Mujer de forma total y sin solapamiento.
PERSONA
sexo
HOMBRE MUJER
Una entidad Persona podrá pertenecer al subtipo Hombre o al subtipo Mujer

necesariamente, es decir, no existirá una entidad Persona que no sea alguno de estos dos
subtipos y además de forma exclusiva, por lo que una entidad pertenecerá a uno y solo
uno de estos subtipos. Además cada entidad de alguno de estos sutipos vendrá
caracterizada por algún atributo o conjunto de atributo definidos para estos subtipos o

heredados del tipo entidad Persona, más el atributo sexo el cual tiene la función
clasificador de las entidades Persona en alguno de los subtipos.
Parcial sin solapamiento
A continuación se muestra un ejemplo de especialización parcial exclusiva. En este caso

se ha considerado un tipo de Enfermedad que puede ser especializada en dos subtipos
Virica y Bacteriana.
ENFERMEDAD
tipo
BACTERIANA VIRICA
Este diagrama representa el hecho de que en el problema se consideran un

conjunto de entidades enfermedad las cuales pertenecerán bien a alguno de los subtipos
considerados Virica o Bacteriana, pero que además existirán entidad Enfermedad las
cuales no pueden ser clasificadas en ninguno de estos subtipos debido, posiblemente, al
desconocimiento del valor del atributo tipo utilizado como discriminador.
Total con solapamiento
Se presenta el refinamiento total con solapamiento en el que un tipo de entidad Empresa

se ha refinado en dos subtipos Publica y Privada.
EMPRESA
clase
PUBLICA PRIVADA
administración empresa
Se está representando el hecho de que podrán existir en el dominio del problema

entidades que puedan ser consideradas tanto Publica como Privada o bien e ambos tipos

al mismo tiempo y además el hecho de que no podrán existir entidades que no puedan ser
especializada en algunos de estos dos subtipos.
Parcial con solapamiento
En este caso se ha representado a un tipo de entidad Persona que puede ser refinado en
dos subtipos Trabajador y Estudiante de forma parcial con solapamiento.
PERSONA
tipo
TRABAJADOR ESTUDIANTE
#nss matricula
Este ejemplo representa que una entidad Persona puede ser del tipo Trabajador y/o
Estudiante y que además puede existir entidades Personas que no puedan clasificarse en
ninguno de estos dos subtipos.
En estos dos últimos ejemplos, los tipos de entidad incorporan nuevos atributos
mediante los cuales pueden diferenciarse entidades pertenecientes a los distintos subtipos
(o del tipo de entidad general en el caso de la especialización no sea total). Igualmente
podrían existir atributos pertenecientes al tipo de interpelación jerárquica cuya función
fuera esta diferenciación de las entidades pertenecientes a los subtipos.

Ejemplo de aplicación
El catastro municipal
Se desea considerar la información correspondiente al catastro de viviendas de un

determinado municipio. En el municipio existe una serie de zonas urbanas en las cuales se
ha edificado un conjunto de viviendas las cuales pueden ser:
• viviendas unifamiliares o casas en las que sólo habita una familia y,
• bloques de pisos en los cuales existe un conjunto de viviendas, indeterminado
a priori, en cada una de las cuales habita una familia.
En el sistema es necesario mantener información correspondiente a las personas que

viven en cada una de las viviendas, así com la cabeza de familia de las personas que
habitan o son propietarias de las viviendas. Para cada vivienda, ademas de al información
correspondiente a las características de las mismas, es necesario conocer al propietario.
Se van a considerar los siguientes supuestos semánticos en el problema:

1. Toda persona habita en una y sólo una vivienda, la cual es considerada como su
vivienda o residencia principal.
2. Cada vivienda tiene uno y sólo un propietario.
3. Las viviendas se encuentran en una única zona urbana correspondiente al
municipio, de las cuales interesa mantener información.
4. Las zonas urbanas en las que está dividido el municipio tienen nombres diferentes.
5. En cada zona urbana del municipio existen una serie de calles en las que se
construyen las viviendas. Los nombres de las calles son únicos para el municipio
con independencia de las zona urbana en las que se encuentren (para simplificar el
problema no se considerará información sobre las calles).
6. En el contexto del problema, una familia es un conjunto de personas que tienen
una relación familiar directa y que habita, o no, en una misma vivienda. Este
conjunto podrá ser unario.
7. Como se indica en el enunciado del problema las viviendas pueden ser casas
unifamiliares o bloques de pisos en los cuales existen una serie de viviendas
unifamiliares.
Una vez que se leen los supuestos semánticos que intervienen en los sistema, así
como las características que poseen, es importante identificar las entidades, lo que
representa, sus atributos y el tipo de entidad, para ello se puede hacer uso de una tabla
como la que se muestra a continuación.

Entidad Que representa Atributos y su descripción Tipo

Zona Objeto del mundo real Se consideran los siguientes atributos: Fuerte
Urbana “colonia” que se define • nombre_zona: identifica de manera única
como la zona a la zona urbana.
geográfica donde se • od_zona: hace referencia a cualquier otro
encuentran las dato que considere sea de interés
viviendas. representar.
Vivienda Objeto del mundo real Se consideran los siguientes atributos: Débil por
que representa a la zona • calle existencia, pues
en la cual se ha • numero no existe si no
construido un edificio Estos dos campos son los que identifican de hay una zona
que servira como manera única a esta entidad. urbana
vivienda. Existen dos • codigo_postal:
tipos de vivienda: las • metros: metros cuadrados del solar o del
unifamiliares y las que edificio.
son bloque de piso. • od_vivienda: hace referencia a cualquier
otro dato que considere sea de interés
representar.
Casa Subtipo de la entidad Ademas de atributos como calle y numero se Debil por
Particular Vivienda, hace consideran: existencia
referencia a aquellas • metros_c: metros cuadrados de la casa
viviendas en las cuales particular
solo vive una familia • od_casa: hace referencia a cualquier otro
dato que considere sea de interés
representar.
Bloque de Subtipo de la entidad Ademas de atributos como calle y numero se Debil por
casas Vivienda, hace consideran: existencia
referencia a aquellas • metros_b: metros cuadrados de la casa
viviendas en las cuales particular
solo vive una familia • od_bloque: hace referencia a cualquier
otro dato que considere sea de interés
representar.
Piso Representa cada una de Para su identificación se necesitan atributos Debil por
las viviendas que tales como: existencia e
pueden existir en un • metros_p: metros cuadrados de la casa identificación ya
bloque de pisos. particular que es necesario
• od_piso: hace referencia a cualquier otro conocer la calle
dato que considere sea de interés y numero del
representar. piso donde su
ubica
Persona Representa el objeto del Para esta entidad se van a considerar 4 tipos Fuerte
mundo real “personas de atributos:
que viven o son • curp: atributo que identifica de manera
propietarias de una unica a cada ocurrencia de esta entidad.
determinada vivienda” • nombre_persona
• apellidos_persona
• od_persona: hace referencia a cualquier
otro dato que considere sea de interes
representar.

Entidades Cardinalidad Cardinalidad

Relación Que representa
que relaciona mínima máxima
UBICA Zona Urbana / Que una vivienda se ubica 1:1 en una zona 1:N en una
Vivienda dentro de una zona urbana urbana puede haber al zona urbana
menos una vivienda y pueden existir
una vivienda solo muchas
puede estar ubicada viviendas.
en una zona urbana
HABITA Vivienda / La relacion que existen 0:1 una vivienda 1:N una
Persona entre las personas que puede estar habitada vivienda
habitan una vivienda, este o no puede estar
tipo de relación se da de habitada por
manera exclusiva entre Casa una o mas
Particular y Piso pues vive personas.
en una o en otra pero no es
la dos.
PROPIETARIO Vivienda / Representa a los 1:1 todas las 1:N una
Persona porpietarios de las viviendas viviendas deben tener persona puede
un propietario y solo ser propietaria
uno de varias
viviendas.
COMPONE Piso / Bloque Representa a los pisos que 1:1 Un piso se ubica 2:N los
casas se existen a cada uno de los en un y solo un bloques de
bloques de casa bloque de casa casa se
componen de
al menos dos
pisos o mas
CABEZA_FAM Persona / Tipo de relación reflexiva, 1:1 cada persona es 1:N o bien
ILIA Persona que existe entre una familia cabeza de familia de puede ser
y la cabeza de familia una persona (ella cabeza de
misma) familia de
varias
personas
Con la información recabada en las tablas se procede a elaborar el diagrama entidad -

relación que se muestra a continuación. 

calle
numero curp
codigo_postal nombre_persona
nombre_zona metros apellidos_persona
od_zona od_vivienda od_persona
ZONA_URBANA VIVIENDA PERSONA
N
N
1:
1:
tipo_vivienda
N
1:
metros_b CABEZA_FAMILIA
od_bloque BLOQUE_PISOS CASA
metros_c
od_casa
:1
escalera
N
planta
puerta
metros_p PISOS
od_piso

UNIDAD 3
MODELO RELACIONAL
• Aplicar el modelo relacional para la generación de esquemas de bases de datos.

Modelo Relacional
El modelo relacional fue propuesto por E. F. Codd en 1970, gracias a su coherencia y
facilidad de uso, este modelo se ha convertido en el más usado para la producción de
sistemas manejadores de base de datos.
El modelo relacional esta basado en la lógica de predicados y la teoría de

conjuntos. La lógica de predicados, que se usa extensamente en las matemáticas, es una
estructura en la que una aseveración (enunciado de un hecho) puede ser verificada como
cierta o falsa. Por ejemplo una afirmación tal como la que un estudiante con numero de
matricula 87048228 se llama Sinforiano Godínez, es fácil demostrar que es cierto o falso.
La teoría de conjuntos es una ciencia matemática que se refiere a conjuntos o grupos de
coas y se usa como la base de la manipulación de datos en el modelo relacional.
Con base en estos conceptos, el modelo relacional tiene tres componentes bien
definidos:
1. Una estructura lógica de datos representada por relaciones, la cual se tratará en esta
sección.
2. Un conjunto de reglas de integridad para hacer cumplir que los datos sean y sigan
siendo consistentes a lo largo del tiempo, lo que se tratara en la sección de “Diseño
de bases de datos relacionales" (normalización).
3. Un conjunto de operaciones que definen la forma en la que los datos se manipulan,
tema que se abordara en la sección de “Álgebra relacional”.
Estructura básica.
La estructura fundamental del modelo relacional es una afinidad (tabla) construida por
tuplas (filas o registros) que representan cada una de las entidades que se consideran
interesantes en la base de datos, cada tupla esta conformada por un conjunto de valores o
campos (columnas) que no son mas que los atributos de las entidades. Las características
de una afinidad se resumen a continuación:
1. Una tabla es percibida como una estructura bidimensional de tuplas y campos.

2. Cada tupla representa una ocurrencia única de entidad dentro del conjunto de
entidades.
3. Cada campo de la afinidad representa un atributo y cada columna tiene un nombre
distinto.
4. Cada intersección de tupla/campo representa un valor único de datos.
5. Todos los valores de una columna deben apegarse al mismo formato de datos.

6. Cada campo tiene un intervalo especifico de valores conocido como dominio de

atributos.
7. Cada tupla debe tener un atributo (o una combinación de atributos) que identifique
de manera única a cada ocurrencia de la entidad.
Los modelos E-R y relacional son representaciones abstractas y lógicas del mundo
real; debido a que los dos modelos emplean principios de diseño similares, se puede
convertir un diagrama E-R en un diseño relacional.
Reducción de DER a Afinidades. Esquemas y llaves.

Para reducir un diagrama E-R al modelo relacional, cada entidad representa una afinidad,
cada instancia de la entidad encontrará sitio en una tupla de la afinidad y los atributos de
la entidad son los campos que conforman la tupla, el campo clave (llave primaria) es el
indice de la afinidad que contendrá valores únicos e irrepetible, y también se representan
los campos con los cuales se establecen las relaciones entre las afinidades, la forma de
escribir esta composición es:
Indice Relación
NOMBRE_TABLA ( CampoClave, Campo1, Campo2, …, Campon, CampoRealacionado )
Entidad Atributos
El nombre de la afinidad debe ir en letra mayúscula y resaltada, los atributos irán

en listados entre paréntesis separados por comas, el índice será el campo clave y debe
estar subrayado y el campo que mostrara la relación en cursivas, por ejemplo:
DORMITORIO 1:
N ESTUDIANTE
Ubicación NoControl
CantHabitantes Nombre
NoDormitorio Semestre
Renta
La composición de las afinidades de este diagrama entidad relación queda de la

siguiente manera:
DORMITORIO (NoDormitorio, CantHabitantes, Ubicación, Renta)

ESTUDIANTE (NoControl, Nombre, Semestre, NoDormitorio)
Los campos claves o llaves son importantes porque se usan para asegurar que cada
tupla de la afinidad sea identificada de manera única; también se usan para establecer
relaciones entre afinidades y para asegurar la integridad de los datos, un tipo de clave o
llave es la primaria también existen superclaves, claves candidatas y claves secundarias,
las cuales se abordaran en detalle en la sección “Diseño de base de datos relacionales”.
La función de la llave esta basada en un concepto conocido como determinación.

En base de datos, el enunciado “A determina a B” indica que si se conoce el valor del
atributo A, se puede conocer el valor del atributo B; por ejemplo si se conoce el numero
de matricula de un estudiante se puede acceder a toda la información de ese estudiante. La
notación breve del enunciado “A determina a B” es A → B. Si “A determina a B, C y D”
entonces se escribe A → B, C, D.
Para determinar los campos relacionados se deben seguir ciertas reglas de acuerdo
a las cardinanildades máximas de la relación:
• Representaciones de 1:1: Cuando se representan relaciones de uno a uno (1:1), se

almacena la clave de una afinidad como clave relacionada o ajena a la segunda, no
importa cual se mueva.
AUTO-ASIGNACION
EMPLEADO 1:
1 AUTO
NoEmpleado NoLicencia
NombreEmpleado NoSerie
Telefono Color
Marca
Modelo
Por ejemplo para este diagrama las afinidades quedarían de la siguiente manera:
EMPLEADO (NoEmpleado, NombreEmpleado, Teléfono, …)

AUTO (NoLicencia, NoSerie, Color, Marca, Modelo, …, NoEmpleado)
O bien de la siguiente:
EMPLEADO (NoEmpleado, NombreEmpleado, Teléfono, …, NoLicencia)

AUTO (NoLicencia, NoSerie, Color, Marca, Modelo, …)

• Representaciones de 1:N En este tipo de relación se aplican los términos padre e

hijo a las entidades. La entidad que esta del lado uno de la relación es la afinidad
padre y la entidad que esta a lado del muchos es la afinidad hijo. En este tipo de
relación la clave de la afinidad padre debe colocarse como clave ajena en la afinidad
hijo.
PROFESOR 1:
N ESTUDIANTE
NombreProfesor NoControl
Telefono NombreEstudiante
Departamento Carrera
PROFESOR (NombreProfesor, Teléfono, Departamento, …)

ESTUDIANTE (NoControl, NombreEstudiante, Carrera, …,
NombreProfesor)
• Representaciones de N:M La solución es crear una tercera afinidad que represente

la relación, tales afinidades se denominan afinidades de intersección que contienen
como campos las claves de las afinidades relacionadas.
ESTUDIANTE-CLASE
ESTUDIANTE N
:M CLASE
NoControl NoClase
NombreEstudiante NombreClase
• Por ejemplo para este diagrama las afinidades quedarían de la siguiente manera:
ESTUDIANTE (NoControl, NombreEstudiante)

CLASE (NoClase, NombreClase)
ESTUDIANTE-CLASE (NoControl, NoClase)

• Representación de relaciones ES_UN: Para representar esta estructura por medio

de afinidades, se define una afinidad para el supertipo y otra para cada subtipo. Se
coloca después cada uno de los atributos del superviso en la afinidad que lo
representa y cada uno de los atributos de los subtipos en las afinidades que lo
representa. En este punto, las afinidades subtipo no tienen una clave principal, solo
tendrán como clave ajena clave de la afinidad supertipo de la cual derivan
calle
numero
codigo_postal
metros
od_vivienda
VIVIENDA
tipo_vivienda
metros_b
metros_c
od_casa
VIVIENDA (calle, numero, codigo_postal, metros, od_vivienda)

BLOQUE_PISOS (metros_b, od_bloque, calle, numero)
CASA (metros_c, od_casa, calle, numero)
Proceso de definición de la base de datos
El modelo relacional nos permite definir la estructura de la base de datos, es decir, como
están organizados los datos en tablas o afinidades, cuales son los atributos o campos
principales, como están relacionadas esas tablas a través de los campos relacionados
conocidos también como campos foráneas ya que esos campos no pertenecen afinidad
que representa la entidad.

El lenguaje utilizado para describir dicha estructura se conoce con el nombre de

lenguaje de definición de datos (DDL). El archivo de texto DDL da los nombres a las
tablas de la base de datos, da nombres y describe las columnas de dichas tablas, define los
índices, y describe otras estructuras como son las reglas de validación y restricciones de
seguridad.
Algunos productos DMBS no requieren que la base de datos quede definida por un
DDL en formato de archivo de texto. Una alternativa común es proporcionar un medio
gráfico para la definición de una estructura de la base de datos.




unifamiliares.
En la unidad de aprendizaje anterior se ejemplifico como obtener el diagrama

entidad relación. A continuación se describe como se va formado el modelo relacional a
partir de dicho diagrama.

Como puede observarse, las relaciones existentes son de tipo 1:N (uno a muchos) lo que
significa que en este caso se debe identificar las entidades padres y las entidades hijas ya que de
esta manera se sabrá que campo principal de una afinidad pasara como secundario (clave foránea
o extranjera) a otra. Para empezar se identifica que por cada entidad una afinidad, en caso que
hubiese relaciones de N:M por cada una de estas se generaría una afinidad.
calle
numero curp
codigo_postal nombre_persona
nombre_zona metros apellidos_persona
od_zona od_vivienda od_persona
ZONA_URBANA VIVIENDA PERSONA
N
N
1:
1:
tipo_vivienda
N
1:
metros_b CABEZA_FAMILIA
metros_c
od_casa
:1
escalera
N
planta
puerta
metros_p PISOS
od_piso
La entidad ZONA_URBANA es una entidad que participa en una relación de uno a

muchos, siendo una entidad padre, razón por la cual, esta entidad permanece sin recibir atributos
de otras entidades.
ZONA_URBANA(nombre_zona, od_zona)
En la relación de ZONA_URBANA con VIVIENDA, ZONA_URBANA es una entidad

padre y VIVIENDA es entidad hija, por tanto el campo principal de ZONA_URBANA pasa
como secundaria a VIVIENDA. A su vez VIVIENDA se relaciona con PERSONA en este
relación VIVIENDA es la entidad padre y PERSONA la entidad hija.

Observe también que la entidad PERSONA tiene una relación reflexiva, por lo cual existe
otro atributo que hace referencia a una ocurrencia de la misma entidad que se marca como
atributo “externo”.
Como la entidad VIVIENDA es una entidad que pose una especialización, por lo cual el
atributo que cualifica la especialización se incorpora como campo en esta tabla.
VIVIENDA(calle, numero, codigo_postal, tipo_vivienda, metros, od_vivienda, nombre_zona)

PERSONA(curp, nombre_persona, apellidos_persona, od_persona, curp_otro, calle, numero,
escalera, planta, puerta)
En el caso de las entidades CASA_PARTICULAR y BLOQUE_CASA, ambas se tratan

de una especialización de la entidad VIVIENDA, es decir, una casa puede ser particular o un
conjutno de pisos (edificio). Preste atención, ambas entidades heredan los atributos de la entidad
que las derivan, en este caso VIVIENDA. Preste atención en el caso de CASA_PARTICULAR
además se incorpora el atributo curp_otro pues permite representar al propietario de la casa
particular, no sucede lo mismo con BLOQUE_CASA puesto que las personas son propietarias de
los pisos que conforman los bloques de casa.
CASA_PARTICULAR(calle, numero, metros_c, od_casa, curp_otro)

BLOQUE_CASA(calle, numero, metros_b, od_bloque)
En el caso de PISO esta entidad tiene una relación de uno a muchos con BLOQUE_PISO,
siendo PISO una entidad hija y BLOQUE_PISO una entidad padre, por lo cual los atributos de
BLOQUE_PISO pasan como campos externos a piso, obsérvese que estos se marcan como
atributos externos y como campos llaves ya que junto con escalera, planta y puerta son los que
permiten identificar de manera única a ese piso en ese bloque de casas.
PISO(calle, numero, escalera, planta, puerta, metros_p, od_piso, dni_p)
Consideración especial, preste atención al hecho que para las personas que habiten en
casas particulares los atributos escalera, planta y puerta en la entidad PERSONA tomarían
valores nulos, esto podría causar una anomalía (las cuales se trataran en la siguiente unidad), sin
embargo estos campos se necesitarían para identificar en que piso vive determinada persona, este
problema esta impuesto por la exclusividad o habita un piso o una casa particular, no ambas. por
lo cual se agrega una entidad derivada de una relación existente en una especialización en este
caso HABITA_PISO. Y se modifica la entidad PERSONA.

PERSONA(curp, nombre_persona, apellidos_persona, od_persona, curp_otro, calle, numero)

HABITA_PISO(curp, calle, numero, escalera, planta, puerta)
Que pasa si en esta etapa del modelado no se toma en cuenta esta consideración a partir
del esquema semántico del problema, no hay ningún problema, esto se soluciona aplicando la
normalización de las afinidades, sin embargo tomar en cuenta estas consideraciones ahorran
mucho tiempo en el diseño de la base de datos. 

UNIDAD 4
DISEÑO DE BASE DE DATOS

RELACIONALES
• Aplicar la normalización al diseño de los esquemas de la base de datos.

Diseño de base de datos relacionales.

El modelo de datos relacional permite que el diseñador de base de datos se concentre en
la representación lógica de los datos y sus relaciones, más que en los detalles físicos de su
almacenamiento.
El diseño de una base de datos usando el modelo relacional, debe satisfacer los
siguientes objetivos:
1. No-existencia de redundancias para minimizar el espacio requerido de
almacenamiento de información y por tanto reduciendo posibles problemas de
integridad en la información almacenada.
2. Aumentar el desempeño de las operaciones de actualización de la base de datos.
3. Aumentar el desempeño y garantizar la fiabilidad de las consultas realizadas acerca
de la información contenida en la base de datos.
Como las afinidades desempeñan un papel importante en el modelo relacional, es

importante examinarlas más de cerca. Se espera que aplicando de manera correcta el
modelo entidad relación y el modelo relacional para el diseño de bases de datos se tenga
como resultado buenas estructuras de bases de datos, sin embargo, es posible crear malas
estructuras incluso después de un buen diseño. Entonces, ¿cómo se reconoce una mala
estructura de afinidad y cómo se produce una afinidad buena? ¿cómo alcanzo los
objetivos que debe satisfacer mi diseño relacional?, la respuesta a estas interrogantes es a
través de la normalización, la funciona por medio de una serie de etapas llamadas formas
normales.
La normalización es el proceso por el cual se evalúan y corrigen estructuras de

afinidades o tablas a fin de minimizar redundancia de datos, con lo cual se reduce la
probabilidad de anomalías de datos (por actualización, eliminación o insersión); por lo
regular se eliminan esas anomalías redefiniendo la afinidad en dos o más afinidades.
En los años setenta, los teóricos relacionales investigaron los tipos de anomalías a
las que las afinidades eran vulnerables. Alguien encontraba una anomalía, la clasificaba y
pensaba en una forma de prevenirla. Cada vez que esto ocurría mejoraban los criterios
para diseñar las afinidades. Estas clases de afinidades y las técnicas para prevenir las
anomalías son llamadas formas normales. Dependiendo de su estructura, una afinidad
puede estar en una primera forma normal, segunda forma normal o alguna otra.
En 1970, E.F. Codd, estableció la primera, segunda y tercera formas normales

(1FN, 2FN, 3FN). Más adelante se definió la forma normal de Boyce-Codd (BCNF) y
después se definieron la cuarta y quinta formas normales. Las formas normales están

anidadas, esto es, un afinidad en la 2FN también esta en la 1FN y una afinidad en la 5NF,
esta también 4FN, BCNF, 3FN, 2FN, 1FN.
Primera Forma Normal (1NF)

Segunda Forma Normal (2NF)
Tercera Forma Normal (3NF)
Forma Normal de Boyce Codd (BCNF)
Cuarta Forma Normal (4NF)
Quinta Forma Normal (5NF)
* Forma Normal dominio/clave (BKNF)
Relación de las formas normales
Estas formas normales fueron útiles, aunque tenían limitaciones. Ninguna teoría
garantizaba que una de ellas eliminaría todas las anomalías: cada forma sólo eliminaba
algunas. Esta situación cambió en 1981, cuando R. Fagin definió una nueva, llamada
forma normal dominio/clave (DK/NF).
Anomalias de datos
Cuando no se ha realizado un diseño de bases de datos de forma normalizada surgen con
frecuencia ciertos problemas cuando se quiere manipular la base de datos. Se distinguen
tres anomalías básicas:
• Anomalía de inserción: imposibilidad de dar de alta una tupla o registro por no
disponer del valor de un atributo principal.
• Anomalía de borrado: perdida de información por dar de baja una tupla o registro.
• Anomalía de modificación: tiene que ver con la redundancia, es decir, la repetición
de la misma información en tuplas diferentes y consiguientemente la necesidad de
propagar actualizaciones. En general la normalización reduce la redundancia pero
no la elimina por completo.
Por ejemplo, suponga que se tiene la siguiente afinidad RECURSOS_HUMANOS

(Nombre_Emp, NumSS, FechaEntrada, Dirección, NumDep, NombreDep, NumSSJefe),
con la siguiente información.
Nombre_Emp NumSS FechaEntrada Dirección NumDep NombreDep NumSSJefe

Javier Solano 2 18 - 10 - 2003 Calle A #7 10 Ventas 3

Nombre_Emp NumSS FechaEntrada Dirección NumDep NombreDep NumSSJefe

Irma Ruiz 7 21 - 01 - 2013 Calle Z #12 11 Compras 9
Pablo Vizcarra 9 01 - 06 - 2007 Calle J #1 11 Compras -
Isabel Leal 3 25 - 11 - 2001 Calle F #15 11 Compras 9
En general se puede observar que se puede separar la información del empleado y

la información del departamento, en el caso de Pablo Vizcarra se puede concluir que el es
el jefe del departamento compras, si no se separará la información como ejemplo se
pudieran dar anomalías: al querer dar de alta un nuevo departamento, ¿sería necesario dar
de alta un empleado?, la respuesta es no, una cosa es un departamento y otra cosa es un
empleado, en este caso se insertaría una tupla con campos varios.
Lo mismo pasa si se contrata personal pero no se ha asignado a algún

departamento. Además el registro del empleado que sea jefe puede ocasionar problemas
de semántica al contener un valor nulo en el campo NumSSJefe, si se separa esta
información no se pierde, ya que en la afinidad donde se tenga información del
Departamento se tiene la clave del empleado que es jefe de ese departamento, así se
puede de acceder a la información de ¿quién es el jefe de departamento x? y también a
¿quién es el jefe de y?.
Imagínese que solo tengo un empleado en un departamento y se necesita dar de

baja, la pregunta es se debe dar de baja también el departamento, o al contrario
desaparece un departamento pero los empleados serán reasignados a otros departamentos,
si se da de baja el departamento se perdería la información de los empleados. O si solo se
cambia el nombre del departamento, esto traería como consecuencia modificar varios
registros para evitar inconsistencias.
El proceso de normalización
El objetivo de la normalización es asegurar que cada afinidad se apague al concepto de
relaciones bien formadas, es decir, que tengan las siguientes características:
• Cada afinidad representa un solo tema. Por ejemplo una afinidad de curso contendrá
solo datos que pertenecen a cursos, de manera que una afinidad de estudiante solo
contendrá datos relacionados con el estudiante.
• Ningún elemento de datos se guardará innecesariamente en más de una afinidad (las
afinidades tienen mínima redundancia controlada). La razón para este requisito es
asegurar que los datos se actualicen en un solo lugar.

• Todos los atributos que no sean claves primarias (atributos no primales) son
dependientes de la llave primaria. La razón para este requisito es asegurar que los
datos sean identificables de manera única por un valor de llave primaria.
• Cada afinidad está libre de anomalías de inserción, actualización o eliminación. Esto
es para asegurar la integridad y consistencia de los datos.
Para lograr el objetivo, el proceso de la normalización nos lleva por los pasos que
conducen a las formas normales sucesivamente mas altas. El concepto de campos clave o
llaves es central para entender el proceso de normalización.
Claves y dependencias
Una clave esta formada por uno o más atributos que identifican de manera única cada
tupla de una afinidad. Una superllave es cualquier llave que de manera única identifique a
cada renglón. Una llave candidata se puede describir como superllave sin atributos
innecesarios. Una llave foránea es un atributo cuyos valores corresponden con los valores
de la llave primaria de la afinidad relacionada. Una llave secundaria se define como
aquella que se usa estrictamente para fines de recuperación de datos.
La función de la llave esta basada en un concepto conocido como determinación.

En base de datos, el enunciado “A determina a B” indica que si se conoce el valor del
atributo A, se puede conocer el valor del atributo B; por ejemplo si se conoce el numero
de matricula de un estudiante se puede acceder a toda la información de ese estudiante. La
notación breve del enunciado “A determina a B” es A → B. Si “A determina a B, C y D”
entonces se escribe A → B, C, D. Los atributos del lado izquierdo de la flecha se conocen
como determinantes.
El principio de determinación es muy importante porque se usa en la definición del

concepto central de una base de datos relacional conocido como dependencia funcional.
El termino de dependencia funcional se define como sigue: el atributo B es
funcionalmente dependiente de A si A determina a B, en forma mas precisa:
El atributo B es funcionalmente dependiente del atributo A si cada valor de la columna

A determina uno y solo un valor de la columna B.
Por ejemplo si conoce el numero de control de un alumno se puede saber que

carrera esta cursando. Si esto es así, se puede decir que la carrera es funcionalmente
dependiente de numero de control. De manera que NumControl → Carrera.
Es importante recordar que podría ser necesario más de un solo atributo para
definir la dependencia funcional; esto es una clave o llave puede estar compuesta por más
de un atributo. Esta clave de atributos múltiples se conoce como clave o llave compuesta.

Dada la posible existencia de una llave compuesta, la noción de dependencia

funcional se puede refinar más si se especifica una dependencia funcional completa:
Si el atributo B es funcionalmente dependiente de una llave compuesta A pero no de

cualquier subconjunto de esa llave compuesta, el atributo es total y funcionalmente
dependiente de A.
Dos tipos de dependencias funcionales de interés en la normalización son las

parciales y las transitivas. Una dependencia parcial existe cuando hay una dependencia
funcional en la que el determinante es solo parte de la llave primaria. Por ejemplo si (A,
B) → (C, D), B → C y (A,B) es la llave primaria, entonces B → C es una dependencia
parcial porque solo parte de la llave primaria (B) se necesita para determinar el valor de
C.
Existe dependencia transitiva cuando hay dependencias funcionales tal que X → Y,

Y → Z y X es llave primaria. En ese caso, la dependencia X → Z es una dependencia
transitiva porque X determina a Z por medio de Y. Se presentara una dependencia
transitiva solo cuando existe dependencia funcional entre atributos no primos. Una vez
definidas las dependencias funcionales se pueden abordar las formas normales.
Primera forma normal 1NF

Cualquier tabla de datos que cumpla con la definición de una afinidad, se dice que está en
la primera forma normal: las celdas de la tabla deben poseer valores simples y no se
permiten grupos ni arreglos repetidos como valores. Todos los registros en cualquier
columna, deben ser del mismo tipo. Cada columna debe tener un nombre único, el orden
de las columnas en la tabla no es importante. Dos hileras en una tabla no deben ser
idénticas, aunque el orden de las hileras no es importante.
Segunda forma normal 2NF

Una afinidad esta en 2NF cuando es en 1NF y no tiene dependencias parciales. La
conversión se hace solo cuando la 1NF tiene una llave compuesta. Si la 1NF tiene una
llave primaria de un solo atributo, entonces la tabla está automáticamente en 2NF.
Tercera forma normal 3NF

Una afinidad esta en 3NF cuando esta en 2NF y no contiene dependencias transitivas.

Forma normal Boyce-Codd BCNF

Una afinidad esta en BCNF cuando todo determinante de ella sea una llave candidata,
cuando una afinidad tiene solo una llave candidata la 3NF y la BCNF son equivalentes.
Cuarta forma normal 4NF

Una afinidad está en 4NF cuando esta en 3NF y no tiene dependencias de valores
múltiples.
Proceso de normalización
En el siguiente diagrama se presenta una afinidad en 1FN pero que contiene dependencias
parciales y transitivas, a continuación se mostrará el procedimiento para eliminar estas
dependencias minimizando el riesgo de tener anomalías por inserción, modificación o
eliminación, cabe mencionar que en cada paso para normalizar se debe hacer un análisis
de las nuevas afinidades resultantes ya en un paso al eliminar cierto tipo de dependencias
pudieran desaparecer otras o incorporarse nuevas.
PROJ_NUM PROJ_NAME EMP_NUM EMP_NAME JOB_CLASS CHG_HOUR HOURS
Dependencia parcial Dependencia transitiva
Dependencia parcial
1NF: INFO_PROJECT(PROJ_NUM, EMP_NUM, PROJ_NAME, EMP_NAME,

JOB_CLASS, CHG_HOUR, HOURS)
DEPENDENCIAS PARCIALES:
(PROJ_NUM) → (PROJ_NAME)
(EMP_NUM) → (EMP_NAME, JOB_CLASS, CHG_HOUR)
DEPENDENCIAS TRANSITIVAS:
(JOB_CLASS) → (CHG_HOUR)

Muchas ocasiones se utilizan dependencias parciales por razones operativas, sin

embargo, hay que analizar bien esta situación ya que las afinidades que contienen este
tipo de dependencias están sujetas a redundancia de datos, como bien se menciono la
conversión a 2NF se hace solo cuando la 1NF contiene una llave primaria compuesta y la
dependencia de los atributos no primos no es total. La conversión de 1NF a 2NF es
sencilla, para eso se siguen los siguientes pasos:
• Paso 1: Hacer nuevas afinidades para eliminar dependencias parciales; por
cada componente de la llave primaria que actué como determinante en una
dependencia parcial, generar una nueva afinidad con una copia de ese componente
como llave primaria, estos componentes permanecen en la afinidad original. Es
primordial que los determinantes continúen en la afinidad original porque serán las
llaves foráneas para las relaciones que se requieran para vincular las nuevas
afinidades vinculadas a la original.
• Paso 2: Reasignar atributos dependientes correspondientes; los atributos que
son dependientes en una dependencia parcial se remueven de la afinidad original y
se colocan en la nueva afinidad con su determinante, cualquier atributo que no sea
dependiente en una dependencia parcial permanece en la afinidad original.
Aplicando los pasos anteriores las nuevas afinidades en 2NF quedarían de la

siguiente manera:
PROJ_NUM EMP_NUM HOURS
PROJ_NUM PROJ_NAME
EMP_NUM EMP_NAME JOB_CLASS CHG_HOUR
Dependencia transitiva
ASIGNACION(PROJ_NAME, EMP_NUM, HOURS)

EMPLEADO(EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR)
PROYECTO(PROJ_NUM, PROJ_NAME)

Analizando las nuevas afinidades puede observarse que se todavía se tiene la

dependencia transitiva (JOB_CLASS) → (CHG_HOUR) por lo cual, no se esta en 3FN,
para lograr que las afinidades estén en 3NF se realizan los siguientes pasos:
• Paso 1: Hacer nuevas dependencias para eliminar dependencias transitivas; por
cada dependencia transitiva, escriba una copia de su determinante como llave
primaria en una nueva afinidad, es importante que el determinante permanezca en la
afinidad original, para servir como llave foránea.
• Paso 2: Reasignar atributos dependientes correspondientes; identifique los
atributos dependientes de todo determinante identificado en el paso 1 y póngalos en
las nuevas afinidades con sus determinantes, remúevalos de la afinidad original.
Aplicando los pasos anteriores las nuevas afinidades en 3NF quedarían de la

siguiente manera:
PROJ_NUM EMP_NUM HOURS
PROJ_NUM PROJ_NAME
EMP_NUM EMP_NAME JOB_CLASS
JOB_CLASS CHG_HOUR
ASIGNACION(PROJ_NAME, EMP_NUM, HOURS)

EMPLEADO(EMP_NUM, EMP_NAME, JOB_CLASS)
PROYECTO(PROJ_NUM, PROJ_NAME)
TRABAJO(JOB_CLASS, CHG_HOURS)
Es interesante observar las similitudes entre resolver problemas de 2NF y 3NF,

para convertir una afinidad en 1NF a 2NF es necesario eliminar las dependencias
parciales. Para convertir una afinidad de 2NF a 3NF es preciso eliminar las dependencias
transitivas. No importa si la dependencia problema es suprimir la dependencia parcial o

transitiva, la solución es la misma. Generar nuevas afinidades por cada dependencia, las
determinantes de las dependencias permanecen en las afinidad original y se colocan como
llave primaria en las nuevas afinidades. Los dependientes de las dependencias problema
se suprimen de la tabla original y se colocan como atributos no primos de las nuevas
afinidades según corresponda.
No obstante, tenga presente que si bien la técnica es la mimas, es imperativo que

se alcance 2NF antes de continuar a 3NF; es importante asegurarse de eliminar todas las
dependencias parciales antes de las las transitivas. Hasta aquí hemos supuesto que cada
afinidad tiene solo una llave candidata que es la primaria, si una afinidad tiene múltiples
llaves candidatas el proceso general de normalización es el mismo pero hay
consideraciones adicionales.
Por ejemplo si una afinidad tiene múltiples llaves candidatas y una de ellas es una
llave compuesta, la tabla puede seguir teniendo dependencias parciales con base a esa
llave candidata compuesta, aun cuando la llave primaria elegida sea un solo atributo. En
esos casos, siguiendo el proceso descrito, esas dependencias se percibirían como
transitivas y no se resolverían hasta 3NF. El proceso simplificado descrito antes permitirá
al diseñador llegar al resultado correcto, pero por medio de la practica debería reconocer
todas las llaves candidatas y sus dependencias como tales y resolverlas de forma
apropiada. La presencia de múltiples llaves candidatas también puede influir en la
identificación de dependencias transitivas. Previamente una dependencia transitiva se
definía como existente cuando un atributo no primo determinadas otros atributo no primo.
En presencia de múltiples llaves candidatas, la definición de un atributo no primo como
atributo que no sea parte de cualquier llave candidata es critica. Si el determinante de una
dependencia funcional no es la llave primaria sino que es parte de otra llave candidata,
entonces no es atributo primo y no indica la presencia de una dependencia transitiva.
Las afinidades en 3NF funcionarán apropiadamente en bases de datos

transacciones de negocios. Recuerde que una afinidad esta en 3NF cuando esta en 2NF y
no contiene dependencias transitivas. Sin embargo hay ocasiones en las que formas
normales de orden superior son útiles; por ejemplo:
A B C D
Esta afinidad no contiene dependencias parciales, ni dependencias transitivas, pero

se señala que un atributo no primo es determinante de un atributo primal. Esta condición
no viola la 3NF pero no satisface los requisitos de la BCNF porque ésta requiere que todo
determinante de la afinidad sea una llave candidata.

Observe las dependencias funcionales:

(A, B) → (C, D)
(A, C) → (B, D)
C→B
Note que esta estructura tiene dos llaves candidatas: (A, B) y (A, C); la estructura
no tiene dependencias parciales ni transitivas. La condición C → B indica que un atributo
no llave determina parte de la llave primaria y esa dependencia no es transitiva o parcial
porque el dependiente es un atributo primo, por lo cual esta condición hace que no se
satisfagan los requisitos de la BCNF.
Para convertir la estructura de la afinidad para que este en 3NF y BCNF es

necesario cambiar la llave primaria a (A,C), esa acción es apropiada porque la
dependencia C → B significa que C es en efecto, un superconjunto de B.
A C B D
En este punto la afinidad esta en 1NF pero no esta en 2NF puesto que introduce
una dependencia parcial, por lo que hay que seguir con los procedimientos normales para
producir afinidades buenas.
A C D
C B




unifamiliares.
En la unidad de aprendizaje anterior se ejemplifico como obtener el modelo

relacional a partir del diagrama entidad relación. A continuación se analizará si las
afinidades están normalizadas en caso de contener dependencias parciales y transitivas
esta deben normalizarse, se aplican desde la la 1NF, pasando por la 2NF, 3NF y llegar
hasta la forma BCNF, por lo general no es necesario aplicar las formas 4NF ni 5NF.

En caso que detectemos que una afinidad no necesite normalizarse se debe

justificar.
La afinidad ZONA_URBANA se encuentra ya en BCFN pues todos los atributos

son atómicos y las dependencias funcionales son completas entre los atributos no primos
con el único determinante funcional (nombre_zona).
La afinidad VIVIENDA se encuentra en BCFN puesto que el único determinante
funcional es la llave compuesta (calle, numero) y todas las dependencias con el resto de los
atributos es completa.
En el caso de las afinidades CASA_PARTICULAR, BLOQUE_CASA y PISO se
encuentran en BCFN pues presentan las mismas características de VIVIENDA.
La afinidad PERSONA se encuentra en 1NF puesto que todos los atributos son atomicos
y no contienen valores nulos (observe que si no se hubiera realizado la consideración descrita en
la unidad anterior el proceso de normalización detecta esta anomalía), no existen dependencias
parciales, por lo cual esta en 2NF y no existen dependencias transitivas por lo cual satisface 3NF
y BCNF.
La afinidad HABITA_PISO esta en BCNF pues todos los atributos no primos dependen
de forma completa del único determinante funcional (curp) .
 

UNIDAD 5
ÁLGEBRA RELACIONAL
• Aplicar el álgebra relacional para la manipulación de datos 

Álgebra relacional
Una de las grandes ventajas del modelo relacional es que define un álgebra, llamada
álgebra relacional. En el álgebra relacional existen dos tipos de operadores algebraicos
los básicos y los avanzados.
Las bases de datos relacionales efectúan todas las operaciones en las tablas usando
álgebra relacional, aunque normalmente no se permite utilizarla. El usuario interacciona
con la base de datos a través de una interfaz diferente el SQL (Structured Query
Lenguaje, lenguaje de consulta estructurado), un lenguaje declarativo que permite escribir
un conjunto de datos básicamente un lenguaje de manipulación de datos (DML)
Operadores básicos
Los operadores básicos son: unión, diferencia, selección, proyección y producto. Los
operadores unión, diferencia y producto son operadores binarios, mientras que la
selección y proyección son operadores unarios.
Para realizar las operaciones de unión y diferencia es necesario que dos afinidades
que intervienen en la operación sean compatibles, es decir, cada una de las afinidades
debe tener el mismo número de atributos (campos) y los atributos (campos) entre las
columnas correspondientes deben provenir del mismo dominio.
Operador unión (UNION)
La unión de dos afinidades se forma añadiendo las tuplas de una afinidad con las tuplas
de la segunda con el propósito de crear una tercera afinidad. El orden en el cual aparecen
las tuplas de la tercera afinidad no tiene importancia, pero las tuplas duplicadas deberán
ser eliminadas, para que esta operación tenga sentido las afinidades deben ser compatibles
de unión. La unión de las afinidades A y B se escribe: A + B o A UNION B. Por ejemplo,
dadas las siguientes afinidades TABACO1 y TABACO2:
TABACO1
Nombre Licencia Hoja Nic Alq
Camel sin filtro R.J Reynolds Tobacco Co. Turca 1.1 15
Malboro Philips Morris Sin especificar 0.9 12
Coronas Tabacalera S.A. Canaria 0.9 15

Rex Tabacalera S.A. Canaria 0.9 15
TABACO2
Ducados Tabacalera S.A. Sin especificar 1.1 15
Fortuna Tabacalera S.A. Sin especificar 1.0 14
Lucky sin filtro Sin especificar Sin especificar 1.0 15
Habanos Tabacalera S.A. Sin especificar 1.3 15
Obtener TABACO3 = TABACO1 UNION TABACO2
TABACO-3
Ducados Tabacalera S.A. Sin especificar 1.1 15
Fortuna Tabacalera S.A. Sin especificar 1.0 14
Lucky sin filtro Sin especificar Sin especificar 1.0 15
Habanos Tabacalera S.A. Sin especificar 1.3 15
Operador diferencia (MINUS):
La diferencia de dos afinidades es una tercera afinidad que contenga aquellas tuplas que
ocurren en la primera afinidad pero no en la segunda. Las afinidades deben ser
compatibles de unión. La diferencia de dos afinidades A y B se escribe A – B o A MINUS
B. Por ejemplo, obtener TABACO4 = TABACO1 MINUS TABACO2

TABACO4
De la misma forma que en la aritmética, el orden de las afinidades que actuar como
operandos tiene importancia y por tanto A – B no es lo mismo que B – A.
Operador producto (PRODUCT)
El producto de dos afinidades es la concatenación de todos las tuplas de una afinidad con
todos las tuplas de la segunda. El producto de la afinidad A (con m tuplas) y la afinidad B
(con n tuplas) tiene m veces n tuplas. El producto de dos afinidades se escribe A * B, A
TIMES B, A PRODUCT B. Ejemplo: Dada la siguiente afinidad, obtener TABACO5 =
TABACO1 PRODUCT ESTANCOS
ESTANCOS
Propietario Calle Teléfono
La Pajarita El nido, 5 275-5578
El Clavel El Jardín, 23 444-8765
TABACO5
Nombre Licencia Hoja Nic Alq Propietario Calle Teléfono
Camel s.f R.J Reynolds Turca 1.1 15 La Pajarita El nido, 5 275-5578
Camel s.f R.J Reynolds Turca 1.1 15 El Clavel El Jardín, 23 444-8765
Malboro Philips Morris Sin esp. 0.9 12 La Pajarita El nido, 5 275-5578
Malboro Philips Morris Sin esp. 0.9 12 El Clavel El Jardín, 23 444-8765
Coronas Tabacalera S.A. Canaria 0.9 15 La Pajarita El nido, 5 275-5578
Coronas Tabacalera S.A. Canaria 0.9 15 El Clavel El Jardín, 23 444-8765
Rex Tabacalera S.A. Canaria 0.9 15 La Pajarita El nido, 5 275-5578
Rex Tabacalera S.A. Canaria 0.9 15 El Clavel El Jardín, 23 444-8765

Muchas veces la afinidad resultante contiene tuplas sin significado por lo que se
necesitará llevar a cabo otras operaciones para extraer cualquier información.
Operador selección (SELECT)
Esta operación toma un subconjunto de tuplas que cumplen cierta condición. La nueva
afinidad incluirá las tuplas que cumplan con la condición dada. La selección de escribe
SELECT(NombreAfinidad / Condición). Por ejemplo, obtener TABACO6 = SELECT
( TABACO1 / LICENCIA = Tabacalera S.A.)
TABACO6
Operador proyección (PROJECT)
Esta operación selecciona atributos especificados de una afinidad. El resultado es una

nueva afinidad con los atributos seleccionados en otras palabras una proyección
selecciona columnas de una afinidad. La proyección se escribe: PROJECT
(NombreAfinidad / Atributo(s)). Por ejemplo, obtener TABACO7 = PROJECT
(TABACO1/Nombre, Nic, Alq)
TABACO7
Nombre Nic Alq
Camel sin filtro 1.1 15
Malboro 0.9 12
Coronas 0.9 15
Rex 0.9 15
Operadores algebraicos avanzados

Las operaciones relacionales realizadas con estos operadores pueden descomponerse en
un conjunto de operaciones básicas en la que solo intervienen los operadores básicos
explicados anteriormente.

Se trata de operaciones muy potentes que realizan operaciones complejas con las
afinidades que forman parte de un esquema relacional. Estos operadores son: la
intersección y la reunión.
Operador intersección (INTERSECT):
Las intersección de dos afinidades es una tercera afinidad que contiene aquellas tuplas
que aparecen tanto en la primera afinidad como en la segunda afinidad estas afinidades
deben ser compatibles de unión. La intersección de dos afinidades se escribe A
INTERSECT B
La operación de intersección es una operación formada por un conjunto de

operaciones básicas, en particular, por una operación unión y dos operadores diferencia.
Así, la intersección de dos afinidades se puede expresar de la forma siguiente:
A3 = A1 INTERSECT A2
= A2 MINUS ((A1 UNION A2) MINUS A1)
Desde el punto de vista de teoría de conjuntos se puede escribir:
A3 = A1 ∩ A2 = (A2 –( A1 ∪ A2)-A1) = A1-(A1-A2)
Ejemplo, obtener TABACO8 =TABACO1 INTERSECT TABACO2
TABACO8
Operación juntar (JOIN)
Esta operación es una combinación de las operaciones de producto, selección y

posiblemente de proyección.
El juntar dos afinidades, digamos A y B opera como sigue: primero se forma el

producto de A por B. A continuación se hace una selección para eliminar algunas tuplas
(los criterios para la selección se especifican como parte de la operación juntar),
posteriormente (en forma opcional), se eliminan algunos atributos mediante una
proyección. La proyección se escribe: A JOIN(Condición) B. Por ejemplo, obtener
TABACO9 = TABACO1 JOIN (Hoja = Hoja) DESCRIPCION

DESCRIPCION
Hoja Clase Color
Turca y Americana Normal Rubio
Turca y Americana Light Rubio
Holandesa Normal Rubio
Canaria UltraLight Negro
TABACO9
Nombre Licencia Hoja Nic Alq Clase Color
Camel sin filtro R.J Reynolds Tobacco Co. Turca 1.1 15 Normal Rubio
Camel sin filtro R.J Reynolds Tobacco Co. Turca 1.1 15 Light Rubio
Coronas Tabacalera S.A. Canaria 0.9 15 UltraLight Negro
Rex Tabacalera S.A. Canaria 0.9 15 UltraLight Negro



Una vez diseñada y construida la base de datos se deben soportar las siguientes operaciones,
analizaremos las operaciones algebraicas que se realizarán obtener información de las afinidades.
a) Obtener la CURP de todos los propietarios de una casa en la zona centro.
En persona se tiene la curp de todas las personas que son propietarias de las casas que
estan identificadas por una calle y numero, si se quiere filtrar obtener esta información de las
casas que solo estan en la zona centro esa información la tiene vivienda. Esta operación se puede
realizar de dos maneras:
- Con puros operadores básicos: se filtran todas la viviendas de la zona centro

proyectando calle y numero que son los datos que se necesitan para filtrar quienes son
propietarios de esas casas, lo que se desea proyectar es la curp por lo que la operación queda de
la siguiente manera:
PROJECT(SELECT(PERSONA/(PROJECT(SELECT(VIVIENDA/nombre_zona = “centro”))/
calle, numero))/curp.
- Con un operador avanzado: se realiza una junta entre PERSONA Y VIVIENDA y solo
se proyecta el curp de la afinidad resultante.
PROJECT(PERSONA JOIN(calle.PERSONA = calle.VIVIENDA, numero.PERSONA =

Numero.VIVIENDA) VIVIENDA)/curp
b) Obtener todo los propietarios de un piso en el bloque de casas de una determinada calle.

c) Obtener todo los pisos de mas de 50 metros cuadrados cuyo propietario tenga
determinado CURP
d) Obtener todas las zonas de la ciudad en las que solo existen casas particulares.
e) Obtener el número de domicilios particulares que existen en determinada calle.
f) Obtener información de los metros cuadrados de solar, agrupados por zonas urbanas y
ordenados por el número total de metros en cada zona urbana.
La afinidad HABITA_PISO esta en BCNF pues todos los atributos no primos dependen
de forma completa del único determinante funcional (curp) .

UNIDAD 6
LENGUAJE SQL
• Aplicar el lenguaje SQL para la manipulación de datos . 

Lenguaje de Consulta Estructurado

El desarrollo del lenguaje de consulta estructurado (SQL - Structured Query Lenguage)
empezó en las instalaciones de investigación de IBM en San José California a mediados
de los años 70, se considera como un lenguaje de programación declarativo y esta basado
en el álgebra relacional.
SQL es el lenguaje de manejo de datos relacionales de mayor importancia en uso

hoy en día. Ha recibido la aceptación de la ANSI como lenguaje de elección para el
manejo de la estructura de bases de datos y es el lenguaje de acceso a los datos que se
aplica en muchos productos DBMS comerciales, por lo cual se dice que SQL es un
lenguaje normalizado.
Sin embargo, como sucede con cualquier sistema de normalización hay

excepciones para casi todo, de hecho, cada motor de bases de datos tiene sus
peculiaridades y lo hace diferente de otro motor. Las construcciones y las expresiones
permitidas de una puesta en practica particular de SQL (INGRES, SQL SERVER, dBASE
IV , ORACLE, Paradox, MS ACCESS) pueden diferir de alguna forma del estándar
ANSI, en parte porque muchos productos DBMS fueron desarrollados antes de llegar al
acuerdo sobre el estándar y también debido a que los fabricantes han añadido capacidades
o sus productos para adquirir ventajas competitivas.
El lenguaje SQL normalizado (ANSI) no nos servirá para resolver todos los
problemas, aunque si se puede asegurar que cualquier sentencia escrita en ANSI será
interpretable por cualquier DBMS en cualquier computadora y cualquier sistema
operativo. Esto conlleva a que diferentes sistemas de información puedan intercambiar
datos pasando consultas y respuestas SQL entre sí.
Los comandos SQL pueden ser utilizados en forma interactiva, como lenguaje de
consulta, o puede insertarse en programas de aplicación. En este último caso son
procesados por un precompilador y por tanto SQL no se considera como un lenguaje de
programación estrictamente dicho, más bien como un sublenguaje de datos o lenguaje de
acceso a los datos, embebido en otros lenguajes.
SQL es un lenguaje orientado a la transformación que acepta como entrada una o

más afinidades y produce una sola afinidad como salida. El resultado de todas las
consultas SQL es una afinidad; aún si el resultado es una sola cifra, dicha cifra o número
se considera como una afinidad con una sola hilera y una sola columna.

Componentes de SQL
SQL está compuesto por comando, cláusulas, operadores y funciones de agregado. Estos
elementos se combinan en las instrucciones para crear, actualizar y manipular las bases de
datos.
Comandos
Existen dos tipos de comandos SQL:

• DDL (Data Definition Language): lenguaje de definición de datos, que permiten
crear y definir nuevas bases de datos, campos e índices.
COMANDOS DDL
Comando Descripción
CREATE Utilizado para crear nuevas tablas, campos e índices.
DROP Empleado para eliminar tablas e índices.
ALTER Utilizado para modificar tablas agregando campos o combinando
definiciones de campos.
• DML (Data Manipulation Language); lenguaje de manipulación de datos, que

permiten generar consultas para ordenar, filtrar y extraer datos de las bases de datos.
COMANDOS DML
Comando Descripción
SELECT Utilizado para consultar registros (tuplas) de las tablas (afinidades) de la
base de datos que satisfagan u criterio determinado.
INSERT Utilizado para cargar conjuntos de datos en la base de datos en una única
operación.
UPDATE Utilizado para modificar los valores de los campos y registros
especificados.
DELETE Utilizado para eliminar registros de una tabla de una base de datos.

Cláusulas
Las cláusulas son condiciones de modificación utilizadas para definir los datos que desea
seleccionar o modificar
Clausula Descripción
FROM Utilizada para especificar la tabla de la cual se van a seleccionar los registros
WHERE Utilizada para especificar las condiciones que deben reunir los registros
seleccionados en grupos específicos
GROUP BY Utilizada para separar los registros seleccionados en grupos específicos
ORDER BY Utilizada para ordenar los registros seleccionados de acuerdo con un orden
específico
HAVING Utilizada para ordenar los registros seleccionados de acuerdo a un orden

especifico.
ASC Utilizada para ordenar los registros seleccionados de manera ascendente.
DESC Utilizada para ordenar los registros seleccionados de manera descendente.
Funciones de agregado
Se usan dentro de una clausula SELECT en grupos de registros para devolver un único
valor que se aplica a un grupo de registros
Función Descripción
AVG Utilizada para calcular el promedio de los valores de un campo determinado
COUNT Utilizada para devolver el número de registros de la selección
SUM Utilizada para devolver la suma de todos los valores de un campo determinado
MAX Utilizado para devolver el valor más alto de un campo especificado
MIN Utilizado para devolver el calor más bajo de un campo especificado

Operadores Lógicos
Operador Descripción
AND “Y” lógico. Evalúa dos condiciones y devuelve un valor de verdad solo si
ambas son ciertas.
OR “O” lógico. Evalúa dos condiciones y devuelve un valor de verdad solo si una
de las dos o las dos son ciertas.
NOT Negación lógica. Devuelve el valor contrario de la expresión.
Operadores de comparación
Operador Descripción
< Menor que
> Mayor que
<> Distinto de
<= Menor o igual que
>= Mayor o igual que
= Igual que
BETWEEN Utilizado para especificar un intervalo de valores
LIKE Utilizado en la comparación de un modelo
IN Utilizado para especificar registros de una base de datos
Orden de ejecución de los comandos
Dada una sentencia SQL de selección que incluye todas las posibles cláusulas, el orden de
ejecución de las mismas es el siguiente:
1. Cláusula FROM
2. Cláusula WHERE
3. Cláusula GROUP BY
4. Cláusula HAVING
5. Cláusula SELECT
6. Cláusula ORDER BY

Definición de la base de datos

Una base de datos en un sistema relacional está compuesta por un conjunto de tablas, que
corresponden a las relaciones del modelo relacional. En la terminología usada en SQL no
se alude a las relaciones, del mismo modo que no se usa el término atributo, pero sí la
palabra columna, y no se habla de tupla, sino de registro
Para crear una base de datos se utilizan los siguientes comandos:
CREATE DATABASE Nom_base_datos;

USE Nom_base_datos;
Seguido de esto se crean las tablas que conforman la base datos:
CREATE TABLE tabla (

campo1 tipo (tamaño) índice1,
campo2 tipo (tamaño) índice2,
...
CONSTRAINT nombre {PRIMARY KEY (primario1[, primario2
[,...]]) |
UNIQUE (único1[, único2 [, ...]]) |
FOREIGN KEY (ref1[, ref2 [,...]]) REFERENCES tabla externa
[(campo externo1 ,campo externo2 [,...])]})
Para modificar el diseño de una tabla ya existente, se pueden modificar los campos o los
índices existentes, asi mismo se puede eliminar campos e indices:
ALTER TABLE tabla {ADD {COLUMN tipo de campo[(tamaño)]

[CONSTRAINT índice]
CONSTRAINT índice multicampo} |
DROP {COLUMN campo I CONSTRAINT nombre del índice}}
Por ejemplo si se desea agregar un campo salario de tipo moneda a una tabla de
empleados quedaría:
ALTER TABLE Empleados ADD COLUMN Salario CURRENCY
Para eliminar el campo salario de la tabla empleados:
ALTER TABLE Empleados DROP COLUMN Salario

Para agregar un campo relacionado con otra tabla, en este caso a una tabla pedidos
se agrega un campo indice de la tabla empleado, en este caso se asocia a un empleado un
pedido.
ALTER TABLE Pedidos ADD CONSTRAINT RelacionPedidos FOREIGN

KEY (IdEmpleado) REFERENCES Empleados (IdEmpleado)
Para eliminar un indice:
ALTER TABLE Pedidos DROP CONSTRAINT RelacionPedidos
Consultas de Acción
 
Las consultas de acción son aquellas que no devuelven ningún registro, son las
encargadas de acciones como añadir y borrar y modificar registros.
Tanto las sentencias de actualización como las de borrado desencadenarán las

actualizaciones en cascada, borrados en cascada, restricciones y valores por defecto
definidos para los diferentes campos o tablas afectadas por la consulta.
INSERT INTO
Agrega un registro en una tabla. Se la conoce como una consulta de datos añadidos. Esta
consulta puede ser de dos tipo:
• Insertar un único registro
INSERT INTO Tabla (campo1, campo2, ..., campoN)  

VALUES (valor1, valor2, ..., valorN)  
Esta consulta graba en el campo1 el valor1, en el campo2 y valor2 y así

sucesivamente.
• Insertar en una tabla los registros contenidos en otra tabla.: Para seleccionar registros e
insertarlos en una tabla nueva. En este caso la sintaxis es la siguiente:
SELECT campo1, campo2, ..., campoN INTO nuevatabla FROM

tablaorigen [WHERE criterios] 
Se pueden utilizar las consultas de creación de tabla para archivar registros, hacer
copias de seguridad de las tablas o hacer copias para exportar a otra base de datos o

utilizar en informes que muestren los datos de un periodo de tiempo concreto. Por
ejemplo, se podría crear un informe de Ventas mensuales por región ejecutando la misma
consulta de creación de tabla cada mes. Se pueden insertar registros de otras tablas en
otras bases de datos.
DELETE
Crea una consulta de eliminación que elimina los registros de una o más de las tablas
listadas en la cláusula FROM que satisfagan la cláusula WHERE. Esta consulta elimina
los registros completos, no es posible eliminar el contenido de algún campo en concreto.
Su sintaxis es:
DELETE FROM Tabla WHERE criterio  
Una vez que se han eliminado los registros utilizando una consulta de borrado, no
puede deshacer la operación. Si desea saber qué registros se eliminarán, primero examine
los resultados de una consulta de selección que utilice el mismo criterio y después ejecute
la consulta de borrado. Mantenga copias de seguridad de sus datos en todo momento. Si
elimina los registros equivocados podrá recuperarlos desde las copias de seguridad.
UPDATE
 
Crea una consulta de actualización que cambia los valores de los campos de una tabla
especificada basándose en un criterio específico. Su sintaxis es:
UPDATE Tabla SET Campo1=Valor1, Campo2=Valor2, CampoN=ValorN

WHERE Criterio 
UPDATE es especialmente útil cuando se desea cambiar un gran número de

registros o cuando éstos se encuentran en múltiples tablas. Puede cambiar varios campos
a la vez. El ejemplo siguiente incrementa los valores Cantidad pedidos en un 10 por
ciento y los valores Transporte en un 3 por ciento para aquellos que se hayan enviado al
Reino Unido:
 
UPDATE Pedidos SET Pedido = Pedidos * 1.1, Transporte =
Transporte * 1.03 WHERE PaisEnvío = 'UK'
UPDATE no genera ningún resultado. Para saber qué registros se van a cambiar,
hay que examinar primero el resultado de una consulta de selección que utilice el mismo
criterio y después ejecutar la consulta de actualización. Si en una consulta de
actualización suprimimos la cláusula WHERE todos los registros de la tabla señalada
serán actualizados.

Consultas de Selección
Las consultas de selección se utilizan para indicar al motor de datos que devuelva
información de las bases de datos, esta información es devuelta en forma de conjunto de
registros. Este conjunto de registros puede ser modificable.
Consultas básicas
La sintaxis básica de una consulta de selección es la siguiente:
SELECT Campos FROM Tabla
En donde campos es la lista de campos que se deseen recuperar y tabla es el origen

de los mismos, por ejemplo:
SELECT Nombre, Teléfono FROM Clientes
Esta sentencia devuelve un conjunto de resultados con el campo nombre y teléfono

de la tabla clientes. Adicionalmente se puede especificar el orden en que se desean
recuperar los registros de las tablas mediante la cláusula ORDER BY Lista de Campos.
En donde Lista de campos representa los campos a ordenar. Ejemplo:
SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER

BY Nombre
Esta consulta devuelve los campos CodigoPostal, Nombre, Telefono de la tabla

Clientes ordenados por el campo Nombre. Se pueden ordenar los registros por mas de un
campo, como por ejemplo:

BY CodigoPostal, Nombre
Incluso se puede especificar el orden de los registros: ascendente mediante la

cláusula (ASC - se toma este valor por defecto) ó descendente (DESC)

BY CodigoPostal DESC , Nombre ASC
Actividad para puntos extra (1): Investigar para que sirven los predicados ALL, TOP,
DISTINCT, DISTINCTOW y AS

La cláusula WHERE
La cláusula WHERE puede usarse para determinar qué registros de las tablas enumeradas
en la cláusula FROM aparecerán en los resultados de la instrucción SELECT. Después de
escribir esta cláusula se deben especificar las condiciones expuestas en los apartados
anteriores. Si no se emplea esta cláusula, la consulta devolverá todas las filas de la tabla.
WHERE es opcional, pero cuando aparece debe ir a continuación de FROM. Ejemplos:
SELECT Nombre, Teléfono FROM Clientes WHERE Edad > 25
SELECT Apellidos, Salario FROM Empleados WHERE Salario =

21000
SELECT IdProducto, Existencias FROM Productos WHERE

Existencias <= NuevoPedido
SELECT * FROM Pedidos WHERE FechaEnvio = #05-30-2014#
SELECT Apellidos, Nombre FROM Empleados WHERE Apellidos =

'King'
Actividad para puntos extra (2): Investigar para que sirven los operadores LIKE,
BETWEEN e IN
SELECT Apellidos, Nombre FROM Empleados WHERE Apellidos Like

'S*'
SELECT Apellidos, Salario FROM Empleados WHERE Salario

Between 200 And 300
SELECT Apellidos, Salario FROM Empleados WHERE Apellidos

Between 'Lon' And 'Tol'
SELECT IdPedido, FechaPedido FROM Pedidos WHERE FechaPedido

Between #01-01-2016# And #12-31-2016#
SELECT Apellidos, Nombre, Ciudad FROM Empleados WHERE Ciudad

In ('Sevilla', 'Los Angeles', 'Barcelona')

GROUP BY 
Combina los registros con valores idénticos, en la lista de campos especificados, en un

único registro. Para cada registro se crea un valor sumario si se incluye una función SQL
agregada, como por ejemplo Sum o Count, en la instrucción SELECT. Su sintaxis es:
SELECT campos FROM tabla WHERE criterio GROUP BY campos del grupo 
GROUP BY es opcional. Los valores de resumen se omiten si no existe una

función SQL agregada en la instrucción SELECT. Los valores Null en los campos
GROUP BY se agrupan y no se omiten. No obstante, los valores Null no se evalúan en
ninguna de las funciones SQL agregadas.
Se utiliza la cláusula WHERE para excluir aquellas filas que no desea agrupar, y la
cláusula HAVING para filtrar los registros una vez agrupados.
SELECT IdFamilia, Sum(Stock) AS StockActual FROM Productos

GROUP BY IdFamilia
Una vez que GROUP BY ha combinado los registros, HAVING muestra cualquier
registro agrupado por la cláusula GROUP BY que satisfaga las condiciones de la cláusula
HAVING.
HAVING es similar a WHERE, determina qué registros se seleccionan. Una vez

que los registros se han agrupado utilizando GROUP BY, HAVING determina cuales de
ellos se van a mostrar.
SELECT IdFamilia, Sum(Stock) AS StockActual FROM Productos

GROUP BY IdFamilia HAVING StockActual > 100 AND
NombreProducto Like BOS*
AVG  
Calcula la media aritmética de un conjunto de valores contenidos en un campo

especificado de una consulta. Su sintaxis es la siguiente
Avg(expr)  
En donde expr representa el campo que contiene los datos numéricos para los que
se desea calcular la media o una expresión que realiza un cálculo utilizando los datos de
dicho campo. La media calculada por Avg es la media aritmética (la suma de los valores
dividido por el número de valores). La función Avg no incluye ningún campo Null en el
cálculo.

SELECT Avg(Gastos) AS Promedio FROM Pedidos WHERE Gastos > 100
Count  
Calcula el número de registros devueltos por una consulta. Su sintaxis es la siguiente
Count(expr)  
En donde expr contiene el nombre del campo que desea contar. Los operandos de
expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la
cual puede ser intrínseca o definida por el usuario pero no otras de las funciones
agregadas de SQL). Puede contar cualquier tipo de datos incluso texto.
Aunque expr puede realizar un cálculo sobre un campo, Count simplemente cuenta
el número de registros sin tener en cuenta qué valores se almacenan en los registros. La
función Count no cuenta los registros que tienen campos null a menos que expr sea el
carácter comodín asterisco (*). Si utiliza un asterisco, Count calcula el número total de
registros, incluyendo aquellos que contienen campos null. Count(*) es considerablemente
más rápida que Count(Campo). No se debe poner el asterisco entre dobles comillas ('*').
 
SELECT Count(*) AS Total FROM Pedidos
Si expr identifica a múltiples campos, la función Count cuenta un registro sólo si al

menos uno de los campos no es Null. Si todos los campos especificados son Null, no se
cuenta el registro. Hay que separar los nombres de los campos con ampersand (&).
 
SELECT Count(FechaEnvío & Transporte) AS Total FROM Pedidos
Podemos hacer que el gestor cuente los datos diferentes de un determinado campo
 
SELECT Count(DISTINCT Localidad) AS Total FROM Pedidos
Max, Min  
Devuelven el mínimo o el máximo de un conjunto de valores contenidos en un campo

especifico de una consulta. Su sintaxis es:
Min(expr)  
Max(expr)  

En donde expr es el campo sobre el que se desea realizar el cálculo. Expr pueden
incluir el nombre de un campo de una tabla, una constante o una función (la cual puede
ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL).
 
SELECT Min(Gastos) AS ElMin FROM Pedidos WHERE Pais =
'España'
 
SELECT Max(Gastos) AS ElMax FROM Pedidos WHERE Pais =
'España'
Sum  
Devuelve la suma del conjunto de valores contenido en un campo especifico de una

consulta. Su sintaxis es:
Sum(expr)  
En donde expr representa el nombre del campo que contiene los datos que desean
sumarse o una expresión que realiza un cálculo utilizando los datos de dichos campos.
Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante
o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las
funciones agregadas de SQL).
 
SELECT Sum(PrecioUnidad * Cantidad) AS Total FROM
DetallePedido
Subconsultas
Una subconsulta es una instrucción SELECT anidada dentro de una instrucción SELECT,
SELECT...INTO, INSERT...INTO, DELETE, o UPDATE o dentro de otra subconsulta.
Se puede utilizar una subconsulta en lugar de una expresión en la lista de campos

de una instrucción SELECT o en una cláusula WHERE o HAVING. En una subconsulta,
se utiliza una instrucción SELECT para proporcionar un conjunto de uno o más valores
especificados para evaluar en la expresión de la cláusula WHERE o HAVING.
Se puede utilizar el predicado ANY o SOME, los cuales son sinónimos, para
recuperar registros de la consulta principal, que satisfagan la comparación con cualquier
otro registro recuperado en la subconsulta. El ejemplo siguiente devuelve todos los
productos cuyo precio unitario es mayor que el de cualquier producto vendido con un
descuento igual o mayor al 25 por ciento:

SELECT * FROM Productos WHERE PrecioUnidad ANY (

SELECT PrecioUnidad FROM DetallePedido WHERE Descuento
= 0 .25)
El predicado ALL se utiliza para recuperar únicamente aquellos registros de la

consulta principal que satisfacen la comparación con todos los registros recuperados en la
subconsulta. Si se cambia ANY por ALL en el ejemplo anterior, la consulta devolverá
únicamente aquellos productos cuyo precio unitario sea mayor que el de todos los
productos vendidos con un descuento igual o mayor al 25 por ciento. Esto es mucho más
restrictivo.
El predicado IN se emplea para recuperar únicamente aquellos registros de la

consulta principal para los que algunos registros de la subconsulta contienen un valor
igual. El ejemplo siguiente devuelve todos los productos vendidos con un descuento igual
o mayor al 25 por ciento:
SELECT * FROM Productos WHERE IDProducto IN (

SELECT IDProducto FROM DetallePedido WHERE Descuento =
0.25 )
Inversamente se puede utilizar NOT IN para recuperar únicamente aquellos

registros de la consulta principal para los que no hay ningún registro de la subconsulta
que contenga un valor igual.
El predicado EXISTS (con la palabra reservada NOT opcional) se utiliza en

comparaciones de verdad/falso para determinar si la subconsulta devuelve algún registro.
Supongamos que deseamos recuperar todos aquellos clientes que hayan realizado al
menos un pedido:
SELECT Clientes.Compañía, Clientes.Teléfono FROM Clientes

WHERE EXISTS (
SELECT * FROM Pedidos WHERE Pedidos.IdPedido =
Clientes.IdCliente )
Se puede utilizar también alias del nombre de la tabla en una subconsulta para
referirse a tablas listadas en la cláusula FROM fuera de la subconsulta. El ejemplo
siguiente devuelve los nombres de los empleados cuyo salario es igual o mayor que el
salario medio de todos los empleados con el mismo título. A la tabla Empleados se le ha
dado el alias T1:

SELECT Apellido, Nombre, Titulo, Salario FROM Empleados AS

T1 WHERE Salario = ( SELECT Avg(Salario) FROM Empleados
WHERE T1.Titulo = Empleados.Titulo ) ORDER BY Titulo
Consultas de Unión Internas

Las vinculaciones entre tablas se realizan mediante la cláusula INNER que combina
registros de dos tablas siempre que haya concordancia de valores en un campo común. Su
sintaxis es:
SELECT campos FROM tb1 INNER JOIN tb2 ON tb1.campo1 comp

tb2.campo2
Se puede utilizar una operación INNER JOIN en cualquier cláusula FROM. Esto
crea una combinación por equivalencia, conocida también como unión interna. Las
combinaciones equivalentes son las más comunes; éstas combinan los registros de dos
tablas siempre que haya concordancia de valores en un campo común a ambas tablas.
Si empleamos la cláusula INNER en la consulta se seleccionarán sólo aquellos

registros de la tabla de la que hayamos escrito a la izquierda de INNER JOIN que
contengan al menos un registro de la tabla que hayamos escrito a la derecha. Para
solucionar esto tenemos dos cláusulas que sustituyen a la palabra clave INNER, estas
cláusulas son LEFT y RIGHT. LEFT toma todos los registros de la tabla de la izquierda
aunque no tengan ningún registro en la tabla de la izquierda. RIGHT realiza la misma
operación pero al contrario, toma todos los registros de la tabla de la derecha aunque no
tenga ningún registro en la tabla de la izquierda.
El ejemplo siguiente muestra cómo podría combinar las tablas Categorías y

Productos basándose en el campo IDCategoria:
SELECT NombreCategoria, NombreProducto FROM Categorias INNER

JOIN Productos ON Categorias.IDCategoria =
Productos.IDCategoria
En el ejemplo anterior, IDCategoria es el campo combinado, pero no está incluido

en la salida de la consulta ya que no está incluido en la instrucción SELECT. Para incluir
el campo combinado, incluir el nombre del campo en la instrucción SELECT, en este
caso, Categorias.IDCategoria.
También se pueden enlazar varias cláusulas ON en una instrucción JOIN,

utilizando la sintaxis siguiente:

SELECT campos FROM tabla1 INNER JOIN tabla2

ON (tb1.campo1 comp tb2.campo1 AND ON tb1.campo2 comp
tb2.campo2)
OR ON (tb1.campo3 comp tb2.campo3)
También puede anidar instrucciones JOIN utilizando la siguiente sintaxis:
SELECT campos FROM tb1 INNER JOIN (tb2 INNER JOIN [( ]tb3
[INNER JOIN [( ]tablax [INNER JOIN ...)]
ON tb3.campo3 comp tbx.campox)]
ON tb2.campo2 comp tb3.campo3)
ON tb1.campo1 comp tb2.campo2
Un LEFT JOIN o un RIGHT JOIN puede anidarse dentro de un INNER JOIN,

pero un INNER JOIN no puede anidarse dentro de un LEFT JOIN o un RIGHT JOIN.
Consultas de Unión Externas

Se utiliza la operación UNION para crear una consulta de unión, combinando los
resultados de dos o más consultas o tablas independientes. Su sintaxis es:
[TABLE] consulta1 UNION [ALL] [TABLE]

consulta2 [UNION [ALL] [TABLE] consultan [ ... ]]
Puede combinar los resultados de dos o más consultas, tablas e instrucciones SELECT, en
cualquier orden, en una única operación UNION. El ejemplo siguiente combina una tabla
existente llamada Nuevas Cuentas y una instrucción SELECT:
TABLE NuevasCuentas UNION ALL SELECT * FROM Clientes WHERE

CantidadPedidos > 1000
Si no se indica lo contrario, no se devuelven registros duplicados cuando se utiliza

la operación UNION, no obstante puede incluir el predicado ALL para asegurar que se
devuelven todos los registros. Esto hace que la consulta se ejecute más rápidamente.
Todas las consultas en una operación UNION deben pedir el mismo número de
campos, no obstante los campos no tienen porqué tener el mismo tamaño o el mismo tipo
de datos. Se puede utilizar una cláusula GROUP BY y/o HAVING en cada argumento
consulta para agrupar los datos devueltos. Puede utilizar una cláusula ORDER BY al final
del último argumento consulta para visualizar los datos devueltos en un orden específico.




unifamiliares.
En la unidad de aprendizaje anterior se ejemplifico como se normaliza una base de

datos tomando en cuenta el modelo relacional, una vez que se tiene el modelo relacional
normalizado se puede proceder a la creación de la base de datos.
Modelo relacional normalizado

VIVIENDA(calle, numero, codigo_postal, metros, od_vivienda, nombre_zona)

PERSONA(curp, nombre_persona, apellidos persona, od_persona, calle, numero)
CASA_PARTICULAR(calle, numero, metros_c, od_casa, dni_cp)
HABITA_PISO(dni, calle, numero, escalera, planta, puerta)
Se crea un script sql con los siguientes comandos:
/* Catastro.sql
Crear el esquema de la base de datos correspondiente al
problema Catastro Municipal.
Si existe la base de datos se borrar para crear una nueva
base de datos.
*/
DROP SCHEMA IF EXISTS Cap06;
CREATE SCHEMA Cap06;

USE Cap06;
/* Se crean las tablas del esquema propuesto */
CREATE TABLE ZonaUrbana (

nombre_zona VARCHAR(20) NOT NULL,
od_zona LONGTEXT,
CONSTRAINT pk_zon
PRIMARY KEY (nombre_zona),
CONSTRAINT ck_zon
CHECK (nombre_zona = UPPER(nombre_zona)) );
CREATE TABLE Vivienda (

calle VARCHAR(40) NOT NULL,
numero INTEGER(3) NOT NULL,
tipo_vivienda VARCHAR(1),
codigo_postal INTEGER(5),
metros INTEGER(5),
od_vivienda LONGTEXT,
nombre_zona VARCHAR(20) NOT NULL,

CONSTRAINT pk_viv
PRIMARY KEY (calle, numero),
CONSTRAINT ck_num
CHECK (numero > 0),
CONSTRAINT ck_tv
CHECK (tipo_vivienda IN ('C', 'B')),
CONSTRAINT fk_viv_zon
FOREIGN KEY (nombre_zona)
REFERENCES ZonaUrbana(nombre_zona) );
CREATE TABLE Persona (

dni INTEGER(8) NOT NULL,
nombre_persona VARCHAR(20) NOT NULL,
apellidos_persona VARCHAR(40) NOT NULL,
od_persona LONGTEXT,
dni_c INTEGER(8) NOT NULL,
CONSTRAINT pk_per
PRIMARY KEY (dni),
CONSTRAINT fk_per_viv
FOREIGN KEY (calle, numero)
REFERENCES Vivienda(calle, numero),
CONSTRAINT fk_per_per
FOREIGN KEY (dni_c)
REFERENCES Persona(dni) );
CREATE TABLE BloqueCasas (

metros_b INTEGER(4),
od_bloque FLOAT,
CONSTRAINT pk_blo
CONSTRAINT fk_blo_viv
REFERENCES Vivienda(calle, numero)
ON DELETE CASCADE,
CONSTRAINT ck_mb
CHECK (metros_b > 0) );
CREATE TABLE CasaParticular (


metros_c INTEGER(4),
od_casa LONGTEXT,
dni_cp INTEGER(8) NOT NULL,
CONSTRAINT pk_cas
CONSTRAINT fk_cas_per
FOREIGN KEY (dni_cp)
REFERENCES Persona(dni),
CONSTRAINT fk_cas_viv
REFERENCES Vivienda(calle, numero)
ON DELETE CASCADE,
CONSTRAINT ck_mt
CHECK (metros_c > 0) );
CREATE TABLE Piso (

escalera VARCHAR(1) NOT NULL,
planta INTEGER(2) NOT NULL,
puerta VARCHAR(2) NOT NULL,
metros_p INTEGER(3),
od_piso LONGTEXT,
dni_p INTEGER(8) NOT NULL,
CONSTRAINT pk_pis
PRIMARY KEY (calle, numero, escalera, planta, puerta),
CONSTRAINT ck_mep
CHECK (metros_p > 0),
CONSTRAINT fk_pis_blo
REFERENCES BloqueCasas(calle, numero)
ON DELETE CASCADE,
CONSTRAINT fk_pis_per
FOREIGN KEY (dni_p)
REFERENCES Persona(dni) );
CREATE TABLE HabitaPiso (

dni INTEGER(8) NOT NULL,


escalera VARCHAR(1) NOT NULL,
planta INTEGER(2) NOT NULL,
puerta VARCHAR(2) NOT NULL,
CONSTRAINT pk_hap
PRIMARY KEY (dni),
CONSTRAINT fk_hap_cas
FOREIGN KEY (calle, numero, escalera, planta, puerta)
REFERENCES Piso(calle, numero, escalera, planta,
puerta)
ON DELETE CASCADE,
CONSTRAINT fk_hbp_per
FOREIGN KEY (dni)
REFERENCES Persona(dni)
ON DELETE CASCADE );
Una vez creada la base de datos, se puede proceder a su llenado mediante comandos
INSERT TO, los datos de la base de datos se cargaran con el archivo CatastroIns.sql a
continuacion se muestra un ejemplo del comando INSERT para cada tabla.
-- Se inserta en la tabla ZonaUrbana

INSERT INTO ZonaUrbana (nombre_zona,od_zona)
VALUES ('CENTRO','Es la zona correspondiente al centro de la
ciudad');
-- Se inserta en la tabla Vivienda

INSERT
INTO Vivienda (calle, numero, tipo_vivienda,
codigo_postal,
metros, od_vivienda, nombre_zona)
VALUES ('Cruz Conde',20,'B',
14003,60,'Piso','CENTRO');
-- Se inserta en la tablas Persona

INSERT
INTO Persona
(dni,nombre_persona,apellidos_persona,od_persona,
dni_c, calle,numero)
VALUES (44351312,'Juan','Pérez López','H',44351312,
'Ronda de los Tejares',15);

-- Se inserta en la tabla BloqueCasas

INSERT INTO BloqueCasas (calle, numero, metros_b, od_bloque)
VALUES ('Cruz Conde',20,60,null);
-- Se inserta en la tabla CasaParticular

INSERT INTO CasaParticular (calle, numero,
metros_c,od_casa,dni_cp)
VALUES('Avenida el Brillante',15,120,'Casa',15304050);
-- Se inserta en la tablas Piso

INSERT INTO Piso (calle, numero, escalera, planta, puerta,
metros_p, od_piso, dni_p)
VALUES('Cruz Conde',20,'B',1,'2',60,'',60696867);
-- Se inserta en la tabla HabitaPiso

INSERT INTO HabitaPiso (dni,calle,numero,escalera,planta,
puerta)
VALUES (40806020,'Ronda de los Tejares',15,'2',2,'3');

UNIDAD 7
BASES DE DATOS ORIENTADAS

A OBJETOS
• Crear el modelado de bases de datos orientadas a objetos.

Bases de datos orientadas a objetos

Las bases de datos orientados a objetos se propusieron con la idea de satisfacer las
necesidades de las aplicaciones más complejas. El enfoque orientado a objetos ofrece la
flexibilidad para cumplir con algunos de estos requerimientos sin estar limitado por los
tipos de datos y los lenguajes de consulta disponibles en los sistemas de bases de datos
tradicionales.
Este modelo trata de almacenar en la base de datos los objetos completos (estado y
comportamiento). Una base de datos orientada a objetos es una base de datos que
incorpora todos los conceptos importantes del paradigma de objetos:
• Encapsulación – Propiedad que permite ocultar la información al resto de los objetos,

impidiendo así accesos incorrectos o conflictos.
• Herencia – Propiedad a través de la cual los objetos heredan comportamiento dentro
de una jerarquía de clases.
• Polimorfismo – Propiedad de una operación mediante la cual puede ser aplicada a
distintos tipos de objetos.
En bases de datos orientadas a objetos, los usuarios pueden definir operaciones

sobre los datos como parte de la definición de la base de datos. Una operación (llamada
función) se especifica en dos partes. La interfaz (o signatura) de una operación incluye el
nombre de la operación y los tipos de datos de sus argumentos (o parámetros). La
implementación (o método) de la operación se especifica separadamente y puede
modificarse sin afectar la interfaz.
Los programas de aplicación de los usuarios pueden operar sobre los datos
invocando a dichas operaciones a través de sus nombres y argumentos, sea cual sea la
forma en la que se han implementado. Esto podría denominarse independencia entre
programas y operaciones.
En una base de datos orientada a objetos, la información se representa mediante

objetos como los presentes en la programación orientada a objetos. Cuando se integra las
características de una base de datos con las de un lenguaje de programación orientado a
objetos, el resultado es un sistema gestor de base de datos orientada a objetos (ODBMS,
object database management system).
Un ODBMS hace que los objetos de la base de datos aparezcan como objetos de
un lenguaje de programación en uno o más lenguajes de programación a los que dé
soporte. Un ODBMS extiende los lenguajes con datos persistentes de forma transparente,
control de concurrencia, recuperación de datos, consultas asociativas y otras capacidades.

Los ODBMS proporcionan los costes de desarrollo más bajos y el mejor

rendimiento cuando se usan objetos gracias a que almacenan objetos en disco y tienen
una integración transparente con el programa escrito en un lenguaje de programación
orientado a objetos, al almacenar exactamente el modelo de objeto usado a nivel
aplicativo, lo que reduce los costes de desarrollo y mantenimiento.
SQL:2003 , es el estándar de SQL92 ampliado, soporta los conceptos orientados a

objetos y mantiene la compatibilidad con SQL92.
Manifiesto Malcolm Atkinson: características de un

BDOO
En 1989 se hizo el Manifiesto de los sistemas de base de datos orientados a objetos el
cual propuso trece características obligatorias para un ODBMS y cuatro opcionales.
Las trece características obligatorias estaban basadas en dos criterios: debía

tratarse de un sistema orientado a objetos y un SGBD.
Características obligatorias de orientación a objetos:

1. Deben soportarse objetos complejos
2. Deben soportarse mecanismos de identidad de los objetos
3. Debe soportarse la encapsulación
4. Deben soportarse los tipos o clases
5. Los tipos o clases deben ser capaces de heredar de sus ancestros
6. Debe soportarse el enlace dinámico
7. El DML debe ser computacionalmente complejo
8. El conjunto de todos los tipos de datos debe ser ampliable
Características obligatorias de SGBD:

9. Debe proporcionarse persistencia a los datos
10. El SGBD debe ser capaz de gestionar bases de datos de muy gran tamaño
11. El SGBD debe soportar a usuarios concurrentes
12. El SGBD debe ser capaz de recuperarse de fallos hardware y software
13. El SGBD debe proporcionar una forma simple de consultar los datos.
Características opcionales:
1. Herencia múltiple
2. Comprobación de tipos e inferencia de tipos
3. Sistema de base de datos distribuido
4. Soporte de versiones

Estructura de una BDOO

El paradigma orientado a objetos se basa en el encapsulamiento de datos y del código
relacionado con cada objeto en una sola unidad. Conceptualmente, todas las interacciones
entre cada objeto y el resto del sistema se realizan mediante mensajes. Por lo tanto, la
interfaz entre cada objeto y el resto del sistema se define mediante un conjunto de
mensajes permitidos.
En general, cada objeto esta asociado con:

• Un conjunto de variables que contiene los datos del objeto; las variables
corresponden con los atributos del modelo E-R.
• Un conjunto de mensajes a los que responde; cada mensaje puede o no tener
parámetros o tener uno o varios.
• Un conjunto de métodos, cada uno de los cuales es el código que implementa un
mensaje; el método devuelve un valor como respuesta al mensaje.
Identidad de objetos
Un sistema de BDOO provee una identidad única a cada objeto independiente
almacenado en la base de datos. Esta identidad única suele implementarse con un
identificador de objeto único, generado por el sistema, u OID. El valor de un OID no es
visible para el usuario externo, sino que el sistema lo utiliza a nivel interno para
identificar cada objeto de manera única y para crear y manejar las referencias entre
objetos.
La principal propiedad que debe tener un OID es la de ser inmutable; es decir, el

valor del OID para un objeto en particular nunca debe cambiar. Esto preserva la identidad
del objeto del mundo real que se está presentando. También es preferible que cada OID se
utilice sólo una vez; esto es aunque un objeto se elimine de la Base de datos, su OID no
se deberá asignar a otro objeto. Estas dos propiedades implican que el OID no debe
depender del valor de ningún atributo del objeto, pues estos valores pueden cambiar.
También suele considerarse inapropiado basar el OID en la dirección física del

objeto en el almacenamiento, ya que una reorganización de los objetos de la base de datos
podría cambiar los OID. Sin embargo, algunos sistemas sí usan la dirección física como
OID para aumentar la eficiencia de la obtención de los objetos. Si la dirección física
cambia, puede colocarse un apuntador indirecto en la dirección anterior, dando la nueva
ubicación física del objeto. Un sistema de BDOO debe contar con algún mecanismo para
generar los OID con la propiedad de inmutabilidad.

Algunos modelos de datos OO requieren que todo se represente como un objeto,

ya sea un valor simple o un objeto complejo; así, todo valor básico, como un entero, una
cadena o un valor booleano, tiene un OID. Con ello dos valores básicos pueden tener
diferentes OID, lo cual es muy útil en algunos casos. Por ejemplo, en algunas ocasiones
se podría usar el valor entero 50 para representar un peso en Kilogramos, y en otras para
referirse a la edad de una persona. Así podrían crearse dos objetos básicos con diferentes
OID, y ambos tendrían el mismo valor básico de 50. Aunque resulta útil como modelo
teórico, esto no es muy práctico porque puede obligar a generar demasiados OID. Por ello
también, la mayor parte de los sistemas de BDOO permiten representar tanto objetos
como valores. Todo objeto debe tener un OID inmutable, pero los valores no tienen OID y
se representan así mismo.
Los objetos tienen identidades únicas, independientes de los valores de sus

atributos.
La estructura orientada a objetos automáticamente impone las restricciones

relacionales, generalmente más aplicables: dominio, llave integridad de entidad e
integridad referencial.
Constructores de tipos
En las BDOO, los valores (o estados) de los objetos complejos se pueden construir a
partir de otros objetos mediante ciertos constructores de tipos. Una forma de representar
tales objetos es considerar a cada objeto como tripleta (i, c, v), donde i es un identificador
de objeto único (el OID), c es un constructor (esto es, una indicación de cómo se
construye el valor del objeto) y v es el valor (o estado) del objeto. Puede haber varios
constructores, según el modelo de datos y el sistema OO.
Los tres constructores básicos son:

• constructores de átomos.
• constructores de tuplas.
• constructores de conjuntos.
Otros constructores de uso más común son los de listas y de arreglos. También
existe un dominio D que contiene todos los valores atómicos básicos que están
disponibles directamente en el sistema. Por lo regular estos incluyen los enteros, los
números reales, las cadenas de caracteres, los tipos boléanos, las fechas y cualesquiera
otros tipos de datos que el sistema maneje directamente.

Encapsulamiento
Tanto la estructura de los objetos como las operaciones que se pueden aplicar a ellos se
incluyen en las definiciones de clases de los objetos.
Compatibilidad con lenguajes de programación

Si se sigue el enfoque cuando se utilizan los diagramas de Entidad-Relación para modelar
los datos y luego se convierten de manera manual en un conjunto de relaciones; por lo
tanto los conceptos de la Programación Orientada a Objetos se utilizan simplemente
como herramientas de diseño y se codifican, utilizándose para trabajar con una base de
datos.
Hay varios lenguajes posibles en los que se pueden integrar estos conceptos:
• Una opción es extender un lenguaje para el tratamiento de datos como el SQL

añadiendo tipos complejos y la programación orientada a objetos. Los sistemas
proporcionan extensiones orientadas a objetos a los sistemas relacionales se
denominan sistemas relacionales orientados a objetos.
• Otra opción es tomar un lenguaje de programación orientado a objetos ya existente y
extenderlo para que trabaje con las bases de datos. Estos lenguajes se denominan
lenguajes de programación persistentes. Estos lenguajes permiten a los programadores
trabajar directamente con los datos, desde el lenguaje de programación; sin tener que
pasar por un lenguaje para el tratamiento de datos como SQL. Se denominan
persistentes porque los datos siguen existiendo una vez que el programa que los creó
ha concluido.
A la hora de decidir que opción utilizar se debe tener en cuenta que los Lenguajes
Persistentes suelen ser potentes y resulta relativamente sencillo cometer errores de
programación que dañen las bases de datos. La complejidad de los lenguajes hace la
optimización automática de alto nivel, como la reducción de E/S de disco, resulte difícil.
En muchas aplicaciones, la posibilidad de las consultas declarativas es de gran
importancia, pero los lenguajes persistentes no permiten actualmente las consultas
declarativas sin que aparezcan problemas de algún tipo.
Jerarquía de tipos y herencia

Los esquemas de BDOO suelen necesitar un gran número de clases. Sin embargo, varias
clases son parecidas entre sí.

Para permitir la representación directa de parecidos entre las clases, hay que
ubicarlas en una jerarquía de especializaciones. El concepto de jerarquía de clases es
parecido al de especialización del modelo E-R.
Las especializaciones de las clases son denominadas subclases; lo cual especifica

atributos y métodos adicionales para una clase existente. Los objetos creados por medio
de unas subclases heredan todos los atributos y métodos de la clase padre. Algunas de
estas características heredadas pueden ellas mismas haber sido heredadas de clases más
altas en la jerarquía.
Manejo de objetos complejos

Los objetos se consideran complejos porque requieren un área de almacenamiento
sustancial y no forman parte de los tipos de datos estándar que suelen ofrecer los SGBD.
Puesto que el tamaño de los objetos es considerable, un SGBD podría obtener una
porción del objeto y proporcionarla al programa de aplicación antes de obtener todo el
objeto. El SGBD podría también usar técnicas de almacenamiento intermedio y caché
para obtener por anticipado porciones del objeto, antes de que el programa de aplicación
necesite tener acceso a ellas.
En un ODBMS, esto puede lograrse definiendo un nuevo tipo de datos abstracto

para los objetos no interpretados y suministrados los médos para seleccionar, comprar y
exhibir tales objetos.
Como un ODBMS permite a los usuarios crear nuevos tipos, y como un tipo
incluye tanto estructura como operaciones, podemos considerar que un ODBMS tiene un
sistema de tipos extensibles. Podemos crear bibliotecas de nuevos tipos definiendo su
estructura y operaciones, incluso con tipos complejos.
Muchos ODBMS pueden almacenar y obtener objeto no estructurado extenso en

forma de cadenas y caracteres o de bits, que se pueden pasar “tal cual” al programa de
aplicación para que las interprete.Es posible almacenar y manipular objetos complejos
tanto estructurados como no estructurados.
Polimorfismo
El polimorfismo se refiere al uso de la misma firma de mensaje para dirigir diferentes
métodos en diferentes clases. Cuando el diseñador envía una señal a un objeto, el método
de la clase de objeto, posiblemente heredado, procesa la señal.

Un método puede tener acceso directamente a atributos de un objeto destino por no

nombre, al incluir cualesquiera atributos heredados de clases padres, pero debe tener
acceso a atributos de otros objetos con señales secundarias.
En síntesis este concepto permite enlazar el mismo nombre o símbolo de operador a dos o
más implementaciones diferentes del operador, dependiendo del tipo de objetos a los que
éste se aplique.
Creación de versiones
Muchas aplicaciones de bases de datos que usan sistemas OO requieren la existencia de
varias versiones del mismo objeto.
Por lo regular, se aplican actividades de mantenimiento a un sistema de software

conforme sus requerimientos evolucionan. Por lo regular, el mantenimiento implica
modificar algunos de los módulos de diseño y de implementación. Si el sistema ya está
en operación, y si es preciso modificar uno o más módulos, el diseñador deberá crear una
nueva versión de cada uno de ellos para efectuar cambios.
Cabe señalar que puede haber más de dos versiones de un objeto. En caso que se
requieran dos versiones, además del módulo original. Se puede actualizar
concurrentemente las propias versiones del mismo módulo del software. Esto se llama
ingeniería concurrente. Sin embargo, siempre llega el momento en que es preciso
combinar (fusionar) estas dos versiones para que la versión hibrida incluya los cambios
realizados. Es necesario de que sus cambios sean compatibles.
Un objeto complejo, como un sistema de software, puede constar de muchos

módulos. Cuando se permite la creación de múltiples versiones, es posible que cada una
de esos módulos tenga varias versiones distintas y un grafo de versiones.
Como se deduce del análisis anterior, un SGBDOO debe ser capaz de almacenar
y controlar múltiples versiones del mismo objeto.
Ventajas de las BDOO

La clave que posee la BDOO es el poder que confieren al diseñador para especificar tanto
la estructura de objetos complejos como las operaciones que se pueden aplicar a esos
objetos.
Está su flexibilidad, y soporte para el manejo de tipos de datos complejos. Por

ejemplo: En una base de datos convencional, si una empresa adquiere varios clientes por
referencia de clientes servicio, pero la base de datos existente, que mantiene la
información de clientes y sus compras, no tiene un campo para registrar quién

proporcionó la referencia, de qué manera fue dicho contacto, o si debe compensarse con
una comisión, sería necesario reestructurar la base de datos para añadir este tipo de
modificaciones. Por el contrario, en una BDOO, el usuario puede añadir una “subclase”
de la clase de clientes para manejar las modificaciones que representan los clientes por
referencia.
La subclase heredará todos los atributos, características de la definición original,

además se especializará en especificar los nuevos campos que se requieren así como los
métodos para manipular solamente estos campos Naturalmente se generan los espacios
para almacenar la información adicional de los nuevos campos. Esto presenta la ventaja
adicional que una BDOO puede ajustarse a usar siempre el espacio de los campos que son
necesarios, eliminando espacio desperdiciado en registros con campos que nunca usan.
La segunda ventaja de una BDOO, es que manipula datos complejos en forma

rápida y ágilmente. La estructura de la base de datos está dada por referencias (o
apuntadores lógicos) entre objetos.
Desventajas de una BDOO

Al considerar la adopción de la tecnología orientada a objetos, la inmadurez del mercado
de BDOO constituye una posible fuente de problemas por lo que debe analizarse con
detalle la presencia en el mercado del proveedor para adoptar su producto en la línea de
producción sustantiva. Por eso en este artículo se propone que se explore esta tecnología
en un proyecto piloto.
El segundo problema es la falta de estándares en la industria orientadas a objetos.

Sin embargo, el “Grupo Manejador de Objetos” (OMG), es una Organización
Internacional de Proveedores de Sistemas de Información y usuarios dedicada a promover
estándares para el desarrollo de aplicaciones y sistemas orientados a objetos en ambiente
de cómputos de red. La implantación de una nueva tecnología requiere que los usuarios
iniciales acepten cierto riesgo. Aquellos que esperan resultados a corto plazo y con un
costo reducido quedarán desilusionados. Sin embargo, para aquellos que planean a un
futuro intermedio con una visión tecnológica avanzada, el uso de tecnología avanzada, el
uso de tecnología orientada a objetos, paulatinamente compensará todos los riesgos.


Apuntes FBD2018

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Apuntes FBD2018

Diunggah oleh

Hak Cipta:

Format Tersedia

Fundamentos de Bases de Datos

Instituto Tecnológico Superior de

División de Ingeniería en Sistemas Computacionales

Ingeniería en Sistemas Computacionales

Ingeniería en Tecnologías de la Información y

Fundamentos de Base de Datos

Apuntes Recopilados por:

Apuntes recopilados por:

En la unidad dos, se revisa el modelo Entidad-Relación como una herramienta que

En la unidad cuatro, se asegura que el diseño de los esquemas de bases de datos

En la unidad seis, se realizan consultas SQL con el fin de entender la estructura de

En la unidad siete, se revisa el paradigma orientado a objetos y sus consideraciones

Apuntes recopilados por:

• Identificar y analizar necesidades de información para su representación,

• Identificar las estructuras básicas de las matemáticas discretas y aplicarlas en el

David M. Kroenke. (2003). Procesamiento de Base de Datos. Fundamentos, diseño e

Apuntes recopilados por:

SISTEMAS GESTORES DE BASE

• Identificar la arquitectura, los usuarios, niveles de abstracción y lenguajes de un

Apuntes recopilados por:

Sistemas Gestores de Base Datos

Aún así, muchos desarrolladores de software bautizaban a sus sistemas de archivos

Estos sistemas de procesamiento de datos representan una significativa mejoría

Apuntes recopilados por:

pudieran no actualizarse, causando discrepancias. Los problemas de integridad de

Sistemas de procesamiento de base de datos

Esta diferencia es significativa: hace más fácil la tarea de programar la aplicación.

• Datos integrados: Es un sistema de base de datos todos los datos se almacena en

Apuntes recopilados por:

Definición de base de datos

• Una base de datos es una recopilación de información almacenada en forma

¿Por qué es un conjunto de registros integrados? Por la jerarquía natural de los

‣ Los metadatos, que es la descripción de la base de datos (tablas y columnas) Tablas:

Apuntes recopilados por:

• Una base de datos es un modelo de un modelo.

Es tentador decir que una base de datos es un modelo de la realidad o de alguna

Las organizaciones cambian, la gente va y viene, a medida que estos cambios

A continuación se presentan un concepto de base de datos que abarca en gran parte

Objetivos de las bases de datos

Apuntes recopilados por:

★ Evitar perdida de información de vital importancia para el usuario ya sea un

Para cumplir con estos objetivos independientemente de la arquitectura de la base

• Versatilidad para la representación de la información: Si bien la información

Apuntes recopilados por:

vital importancia y valor para la organización responsable de la misma. A medida

En términos generales, un modelo es una abstracción de un objeto o hecho real

El modelado de datos es un proceso iterativo y progresivo. Se empieza con una

Este plano es narrativo y gráfico en su naturaleza, lo cual significa que contiene

Un modelo de datos listo para la implementación debe contener al menos los

Los modelos de datos pueden facilitar la interacción entre el diseñador, el

Apuntes recopilados por:

promover un mejor entendimiento de la organización para la cual se desarrolló el diseño

Cuando se dispone de un buen plano de la base da datos, no importa que la vista

Los elementos básicos de un modelo de datos son: entidades, atributos, relaciones

Apuntes recopilados por:

• Visión conceptual: Es la visión del problema tal y como éste se presenta en el

Arquitectura de un sistema gestor de base datos

Hasta estos momentos se ha estado tratando únicamente el termino de base de

Pero para que la información deba estar almacenada como se ha descrito y el

Así, un DBMS es una colección de programas de aplicación que proporcionan al

• Definición de los datos a los distintos niveles de abstracción(físico, lógico, y

Apuntes recopilados por: