Documentos de Académico
Documentos de Profesional
Documentos de Cultura
BDPerspectivaPractica Cardona Et Al 2014
BDPerspectivaPractica Cardona Et Al 2014
Héctor Cardona
Jhon Eder Masso
Maritza Fernanda Mera
Sandra Milena Roa
Edgar Fabián Ruano
María Dolores Torres
María Isabel Vidal
Diseño e Implementación de Bases de Datos desde una Perspectiva Práctica
1a ed. - Iniciativa Latinoamericana de Libros de Texto Abiertos (LATIn), 2014. 147 pag.
Los textos de este libro se distribuyen bajo una licencia Reconocimiento-CompartirIgual 3.0 Un-
ported (CC BY-SA 3.0) http://creativecommons.org/licenses/by-sa/3.0/deed.es_
ES
Las figuras e ilustraciones que aparecen en el libro son de autoría de los respectivos
autores. De aquellas figuras o ilustraciones que no son realizadas por los autores, se
coloca la referencia respectiva.
Este texto forma parte de la Iniciativa Latinoamericana de Libros de Texto abiertos (LATIn),
proyecto financiado por la Unión Europea en el marco de su Programa ALFA III EuropeAid.
El Proyecto LATIn está conformado por: Escuela Superior Politécnica del Litoral, Ecuador
(ESPOL); Universidad Autónoma de Aguascalientes, México (UAA), Universidad Católica de
San Pablo, Perú (UCSP); Universidade Presbiteriana Mackenzie, Brasil(UPM); Universidad de la
República, Uruguay (UdelaR); Universidad Nacional de Rosario, Argentina(UNR); Universidad
Central de Venezuela, Venezuela (UCV), Universidad Austral de Chile, Chile (UACH), Uni-
versidad del Cauca, Colombia (UNICAUCA), Katholieke Universiteit Leuven, Bélgica (KUL),
Universidad de Alcalá, España (UAH), Université Paul Sabatier, Francia (UPS).
Índice general
3.3 NORMALIZACIÓN 44
3.3.1 Relación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.2 Razones para normalizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.3 Formas Normales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
La importancia de los modelos radica en que permiten representar un universo del discurso o
dominio del negocio haciendo uso de la abstracción, a fin de identificar aspectos importantes
y relevantes para el dominio, esta representación será posible con la ayuda de un lenguaje de
modelado, a fin de entender y comprender un problema complejo que brinde una solución que
dé respuesta a una necesidad.
El universo del discurso (UD) podría definirse como el conjunto de necesidades de un
10 INTRODUCCIÓN A LOS MODELOS DE DATOS
dominio de negocio en particular, que nos permite el modelado e implementación de una base de
datos. En otras palabras, es una descripción clara y precisa sobre el universo o mundo que se
desea modelar.
Un universo del discurso es realizado por expertos o con la ayuda de estos, ya que estos son
los que entienden del negocio; es decir los expertos en la materia. Podríamos decir que un UD es
una descripción del dominio del negocio en términos de un experto que permite la compresión y
la realización del modelado de una base de datos.
Ejemplo de un Universo del Discurso
Fuente: http://www.cristiancaricaturas.com/
“Se desea construir una base de datos para la gestión de una empresa dedicada a la venta de
insumos para la contrucción y alquiler de andamios, la cual esta ubicada en la ciudad de Popayán.
La empresa desea controlar toda la información de ventas, alquiles, empleados, clientes y de
cada una de sus sedes que estan ubicadas por toda la ciudad. Con respecto a las sedes es preciso
tener en cuenta que tienen un identificador principal, dirección, telefono y fax , además estas
deberán estar a cargo de un empleado y un empleado podrá estar a cargo de estas pero en un
determinado tiempo, es decir un empleado no puede tener a cargo más de una sede en un periodo
de tiempo. . . . . . . . . ”
Es importante distinguir en el modelado de datos los conceptos de Esquema y Ejemplar.
Esquema: Es la realidad representada mediante la utilización de modelos en diferentes niveles
de abstracción del proceso de construcción de una base de datos; es aquí en donde se encuentra
la estructura de una base de datos que representa los conceptos e instancias de cada uno de esos
elementos que han sido modelados.
Ejemplar: Entendido como una ocurrencia o instancia de la estructura de la base de datos,
es decir, colección de datos dinámicos que están almacenados y representados con forme a un
esquema en un determinado momento.
Podemos concluir con respecto a los modelos de datos que estos hace uso de un conjunto
de reglas, restricciones y símbolos que han sido definidos para un lenguaje de modelado, con
el fin de representar la semántica de un UD a fin de crear un esquema que permita coleccionar
instancias de cada uno de los elementos pertenecientes a un dominio que fue modelado. Ver
Figura 1.3.
1.2 Componentes de un Modelo de Datos 11
1.2.1 Estática
Esta propiedad es la que define el conjunto de símbolos, reglas y restricciones de un modelo.
La estática de un modelo es lo que permite representar:
Objetos, es decir entidades o conceptos del UD que deseamos representar.
Propiedades o características propias de los objetos, también conocidos como atributos.
Relaciones o asociaciones entre cada uno de los objetos que intervienen en el modelo.
Y restricciones o elementos no permitidos, es decir las limitaciones o reglas de integridad
definidas para los modelo de datos y las que son propias al UD, estas últimas son las
definidas por los expertos del negocio y podrán ser aplicadas a nivel de los objetos y sus
propiedades o en las relaciones entre los mismo objetos.
1.2.2 Dinámica
Esta propiedad comprende todas las operaciones que se pueden realizar sobre el conjunto
de instancias de un esquema. El componente dinámico define un conjunto de operadores para
la realización de operaciones entre objetos, sobre las propiedades de los objetos y entre otras
operaciones.
Algunas de estas operaciones podrían ser de actualización o recuperación de información alojada
en un esquema de base de datos y las cuales serán programadas por un usuario haciendo uso de
lenguaje de consulta el cuál brinda las sentencias necesarias para acceder a la información.
de los usuarios que intervienen en la creación, gestión y manipulación de este tipo de sistemas.
Es decir, una interfaz describe información importante y relevante en términos de los usuarios
involucrados en cada una de ellas. Ver Figura 1.4.
Los niveles que fueron definidos en este estándar son: Externo, Conceptual e Interno;
Respecto al nivel externo podemos decir que hace referencia a una vista de un usuario, la cual
describe sola una parte de la base de datos la cual es relevante para el usuario. Esta vista limita al
usuario a solo ver información que le ha sido autorizada, es decir, una vista que excluye todos
datos que el usuario no le ha sido autorizado o no puede acceder. En este nivel es donde aparecen
las interfaces de aplicaciones de usuario finales y los lenguajes de manipulación de datos.
El nivel conceptual, consiste en la forma de representación cada uno de los elementos de un
UD. Es aquí donde aparecen modelos que permiten la representación y descripción de los datos
en términos de entidades, propiedades y relaciones entre las mismas, además de la integridad,
seguridad y restricciones en los datos. Aquí podemos hablar de un esquema el cual está acorde a
un modelo de datos, es decir, un conjunto formal de reglas que permiten la representación de los
datos y las operaciones entre los mismos.
El nivel interno, define la forma en como los datos serán representados y almacenados física-
mente mediante un sistema informático o gestor de bases de datos, es decir, la definición de
estructuras que permiten el almacenamiento de los datos en la base datos así como también en el
hardware del equipo. En este nivel estaríamos hablando de vistas a nivel de los equipos compu-
taciones y los sistemas informáticos que se encargan de la gestión de bases de datos, además
del esquema físico que es la representación de una base de datos, en términos de un conjunto de
sentencias que son entendidas por un sistema informático en particular. La Figura 1.5 muestra un
resumen de cada uno de los elementos de esta arquitectura mencionados anteriormente.
1.3 Tipos de Modelos de Datos 13
Modelo Conceptual
Este modelo representa una vista abstracta y global de toda la base de datos, en términos
de objetos, propiedades y relaciones. Es decir, describe un esquema básico del cómo se podrán
tratar los datos en un futuro por el modelo interno. El modelo conceptual está más interesado en
la naturaleza básica de la representación del conjunto de necesidades expresadas en el UD. Los
modelos conceptuales son orientados más hacia el análisis de la base de datos que al diseño o
implementación, por tanto estos modelos son independientes de herramientas informáticas, lo
cual quiere decir que no dependen de ningún Sistema Gestor de Bases de Datos (SGBD), a esto
es lo que se le conoce como independencia de los datos con respecto a los modelos externos e
internos.Algunos de los principales modelos conceptuales para la representación de datos son:
El Modelo Infológico (Infological) tiene como finalidad la representación de la informa-
ción conforme a es percibida por las personas, en términos de colección de objetos +
propiedades o relaciones + el tiempo, siendo cada uno de estos los elementos básicos
del modelo. Finalmente este modelo hace más énfasis en los aspectos conceptuales y
estructurales de los datos.
El Modelo de Datos Semántico (Semantic Data Models - SDM) provee un conjunto
de mecanismos que permite realizar un modelado de alto nivel orientado a capturar la
semántica del entorno de la aplicación en términos de los diferentes tipos de entidades
existente en ese entorno, la agrupación e interconexión estructural de las mismas.
14 INTRODUCCIÓN A LOS MODELOS DE DATOS
Modelo Lógico
Estos modelos están más orientados a los SGBD. Estos permitirán la creación del modelo
físico de la base de datos. Estos permiten la creación de los esquemas internos y físicos de la
base de datos, además cumplirán con las características y especificaciones propias del SGBD
que se escogió para la implementación.
Modelo Físico
Es un modelo que describe la abstracción de la base de datos al más bajo nivel, es decir,
describe la forma en cómo serán almacenados los datos, esto dependerá finalmente del SGBD
seleccionado para la implementación el cual es escogido sean las necesidades de los usuarios y
del negocio. Un modelo físico incluirá todas las sentencias conforme a un lenguaje de definición
de datos apropiado para la creación de todos los objetos de la base datos, las relaciones entre
cada una de las tablas, así como también los índices, sinónimos, restricciones, clusters, etc.
Cuando nos referimos al SGBD seleccionado por un usuario, se está haciendo hincapié a las
diferentes bases de datos comerciales existentes en el mercado, como por ejemplo: Informix,
Oracle, Postgres, SQL Server, Sybase, DB2, MySQL, etc.Finalmente, esto modelos están más
orientados hacia la implementación de las bases de datos tomando como punto de partida cada
una de las restricciones de los SGBD, afín de que puedan ser utilizadas por aplicaciones y de los
diferentes usuarios de la base de datos.
Una metodología de diseño y desarrollo de bases de datos puede ser definida como un con-
junto de procedimientos y técnicas agrupadas en etapas que guían al diseñador en el proceso de
construcción de una base de datos facilitando a partir de los requisitos, necesidades o problemas
de un usuario en términos de datos la concepción de una solución física soportada en una base
de datos que le permita obtener la información requerida.
En la figura se presenta los principales elementos que deben considerarse en una metodología
de diseño y desarrollo de un sistema de base de datos simple o complejo.
16 INTRODUCCIÓN A LOS MODELOS DE DATOS
Figura 1.6:
Actividades:
2. Revisar si existen valores que pueden tomar los atributos y en caso afirmativo, determinar
la lista de los posibles valores, los cuales serán llamados en adelante dominios.
3. Determinar los atributos que identifican un conjunto de elementos que tienen características
similares.
4. Seleccionar un Modelo de Datos Conceptual que permitan modelar todos los objetos
encontrados.
5. Crear a partir del modelo de datos seleccionado el respectivo Esquema Conceptual de la
base de datos.
6. Revisar el esquema obtenido garantizando que no exista redundancia de los datos, que
refleje la semántica descrita por el usuario, que soporte transacciones de los usuarios, entre
otros aspectos.
7. Presentar el Esquema Conceptual a los usuarios y realizar las correcciones necesarias para
obtener el Esquema Definitivo acorde a los requisitos.
8. Documentar esta etapa considerando todos los elementos y las relaciones de tipo no
estructural encontradas, es decir, aquellas que deben ser tenidas en cuenta pero que no se
pueden representar por el Modelo de Datos seleccionado, incluir el diccionario de datos.
Actividades:
Actividades:
1.4.5 Ejemplo
UNIVERSO DEL DISCURSO:
En un concesionario de vehículos se desea mediante una base de datos guardar la información
relacionada con los autos y clientes, sabiendo que de los vehículo se tiene el número de matrícula,
color y modelo; se consideran clientes a las personas que han realizado una compra de vehículo
en el concesionario, guardándose los datos del cliente (cédula de ciudadanía, nombres, apellidos,
dirección, celular, fecha de nacimiento) y con respecto a la compra se desea saber la fecha en
que se realizó asimismo el valor y medio de pago utilizado (cheque, efectivo, tarjeta de crédito).
Algunos de los clientes han realizado más de una compra en el concesionario.
g)
2. Se realizará el diseño lógico teniendo en cuenta:
a) Modelo de Datos Lógico seleccionado: Relacional
b) Transformación del esquema conceptual a esquema lógico:
c) Restricciones
d) Elementos no estructurales considerados
3. La validación del esquema relacional se realizará con las Formas Normales o Teoría de la
Normalización y el esquema relacional definitivo es:
1. Indices creados
2. Implementación de mecanismos de seguridad y control de acceso
2 — MODELO CONCEPTUAL: ENTIDAD
INTERRELACIÓN
2.1 Introducción
En este capítulo describiremos el Modelo Entidad Relación (E/R), mencionado en el capítulo
anterior como un modelo de datos y ampliamente utilizado como modelo conceptual en el
diseño de bases de datos relacionales. El modelo E/R debido a su capacidad de expresividad y
abstracción permite representar la semántica de una situación del mundo real en un diagrama fácil
de entender para diseñadores y usuarios. El modelo fue propuesto por Peter Chen en 1976 bajo
el enfoque de representar todo objeto del mundo real en términos de entidades y las relaciones
que se dan entre estas, considerando que esta es la manera más natural de representar el mundo
real. Varios autores han escrito acerca del modelo E/R después de la definición original de Chen,
los autores han realizado algunas mejoras y aportes que amplían y extienden los conceptos para
facilitar el diseño de la base de datos. El modelo E/R facilita el diseño de la base de datos, ya que
permite describirla a un nivel de abstracción capaz de aislar aspectos asociadas a la máquina en
donde se almacenará y los usuarios que la consultarán, y hacer relevancia en representar solo la
información de la semántica del problema. Para Chen, el modelo se basa en identificar aquellas
cosas (o adjetivos) que se identifican claramente para representarlas como entidades y encontrar
las vinculaciones o relaciones que se dan entre ellas según el mundo real. A través de los años
el modelo ha logrado un gran reconocimiento que le ha permitido convertirse en el modelo
conceptual más utilizado y recomendado en el diseño de bases de datos. Si bien, algunos autores
como Christopher Date no consideran el modelo E/R como un modelo conceptual, si reconocen
la gran utilidad para concebir un modelo parcial de la realidad antes de crear las físicamente las
tablas que almacenarán los datos.
2.2.1 Entidad
Una entidad se define como cualquier cosa u objeto del mundo real que puede ser distinguible
y posea existencia propia. La existencia puede ser física o abstracta. Cuando hablamos de
existencia física se hace referencia a los objetos reales que ocupan un espacio físico en la
realidad, mientras que la existencia abstracta se refiere a aquellos elementos que son intangibles y
que se definen conceptualmente. A manera de ejemplos, podemos decir que una persona, un libro
o un carro tienen existencia física y un viaje o una receta de cocina existen conceptualmente.
Cada entidad debe describir a sus ejemplares, registros u ocurrencias por medio de un conjunto
de características o propiedades que son comunes entre ellos, por ejemplo, una entidad persona
describe a todos sus ejemplares a través de las características nombre, identificación y fecha de
22 MODELO CONCEPTUAL: ENTIDAD INTERRELACIÓN
nacimiento; un ejemplar de persona podría ser “Carlos Perez” con identificación 109883 y con
fecha de nacimiento 12/10/1985. Por otro lado, los ejemplares de una entidad deben poderse
distinguir de los demás ejemplares de la misma entidad, por ejemplo, una persona se puede
diferenciar de otra a través de los valores que tomen sus propiedades nombre, identificación y
fecha de nacimiento.
La representación gráfica de una entidad en el modelo E/R se hace a través de un rectángulo y
en su contenido el nombre de la entidad como se muestra en la siguiente figura.
Figura 2.1:
Clases de Entidad
Las entidades pueden clasificarse como fuertes, aquellas que poseen ejemplares que existen
sin depender de la existencia de otro ejemplar, o débiles, en las cuales sus ejemplares dependen
de la existencia de otro ejemplar de otra entidad, por ejemplo, consideremos la entidad LIBRO
en la que se registran los datos de los libros de una biblioteca, sin embargo, para almacenar los
datos de las copias que existen de cada libro se necesita la entidad COPIA, de esta manera el
libro “Cien años de soledad” será almacenado como ejemplar de la entidad LIBRO, mientras
que los datos de todas las copias físicas que existen del libro se almacenarán como ejemplares
de la entidad COPIA. Si eliminamos un ejemplar de la entidad LIBRO se deben eliminar los
datos de las copias físicas de éste, por lo tanto, la existencia de los ejemplares de la entidad
COPIA depende de la existencia de los ejemplares de otra entidad y la debemos clasificar como
una entidad débil. La representación gráfica de una entidad débil en el modelo E/R se hace a
través de dos rectángulos (uno dentro de otro) y en su contenido el nombre de la entidad como se
muestra en la figura 2.2.
Figura 2.2:
Identificación de Entidades
Una de las tareas más complejas en el diseño de un modelo E/R es la identificación de las
entidades, si bien el concepto de entidad puede ser fácil de entender, la aplicación de concepto
para determinar si un objeto o cosa del mundo real es una entidad puede ser ambiguo. A
continuación se enumeran algunos aspectos que se deben considerar para identificar las entidades
en un problema del mundo real:
2.2 Componente Estático 23
En los requisitos o universo del discurso se deben identificar sustantivos que son descritos
a través de un conjunto de propiedades.
Cada entidad identificada debe representar información relevante en el problema del
mundo real que se desea modelar.
Los ejemplares de cada entidad identificada deben poderse diferenciar de los otros ejem-
plares de la misma entidad.
2.2.2 Atributo
Son las propiedades o características que describen a una entidad o relación. Su existencia
depende de la entidad a la que pertenecen y los valores que tomen expresan el estado de un
ejemplar.
La representación gráfica de un atributo en el modelo E/R se hace a través de un ovalo o circulo
como se muestra en la Figura 2.3.
Figura 2.3:
Ejemplo 2.1
Para expresar que la entidad PERSONA tiene un atributo Nombre lo podemos representar
como se muestra en la Figura 2.4.
Figura 2.4:
Tipos de atributos
Simples o Compuestos
Los atributos simples son atómicos, no poseen ninguna estructura interna y almacenan un único
valor. Los atributos compuestos son atributos que poseen varios componentes, se usan cuando
un grupo de atributos tienen alguna afinidad en su significado en el mundo real o cuando su
agrupación en una estructura le da algún significado, por ejemplo, los atributos Día, Mes y Año
los podríamos agrupar en un atributo Fecha que posee una estructura más compleja.
La representación gráfica de un atributo compuesto en el modelo E/R se puede observar en la
Figura 2.5.
24 MODELO CONCEPTUAL: ENTIDAD INTERRELACIÓN
Figura 2.5:
Ejemplo 2.2.
Si consideramos que una persona tiene una característica fecha de nacimiento que se compone
de Día, Mes y Año, en el modelo E/R lo podemos modelar como se muestra en la Figura 2.6.
Figura 2.6:
Figura 2.7:
Ejemplo 2.3.
Si consideramos que una persona tiene dos atributos: FechaNacimiento y Edad, y el atributo
Edad se calcula a partir del atributo FechaNacimiento, el modelo E/R obtenido para esta situación
se puede observar en la Figura 2.8.
Figura 2.8:
2.2 Componente Estático 25
Univaluado y Multivaluados
Los atributos Univaluadospermiten almacenar un único valor para el ejemplar en esta caracterís-
tica. Por defecto cuando se define un atributo en una entidad, éste es univaluado. Los atributos
multivaluados permiten almacenar varios valores para el ejemplar en esta característica. La
representación gráfica de un atributo multivaluado en el modelo E/R se puede observar en la
Figura 2.9.
Figura 2.9:
Ejemplo 2.4.
Si consideramos que de una persona se van a guardar de uno a tres teléfonos, la manera
de representarlo en un modelo E/R es emplear un atributo multivaluado como se muestra en la
Figura 2.10.
Figura 2.10:
Opcionales
Los atributos opcionales son atributos que por lo general almacenan valores nulos o vacíos. Se
utilizan cuando (i) el valor que se desea almacenar sobre el atributo existe pero no se conoce.
(ii) el ejemplar no tiene un valor aplicable en el momento para el atributo, por ejemplo, en
un préstamo de un libro, inicialmente no se conoce la fecha de devolución en que un usuario
devolverá el libro. La representación gráfica de un atributo opcional en el modelo E/R se puede
observar en la Figura 2.11.
Figura 2.11:
Ejemplo 2.5
Si consideramos que algunas personas pueden ser profesionales y por lo tanto, tienen un
registro profesional que se debe almacenar, la manera de representar este dato en el modelo E/R
es a través de un atributo opcional como se muestra en la Figura 2.12.
26 MODELO CONCEPTUAL: ENTIDAD INTERRELACIÓN
Figura 2.12:
Figura 2.13:
Ejemplo 2.6
Consideremos que los ejemplares de la entidad Persona se identifican a partir del número de
célula, la manera de representar este dato en el modelo E/R es a través de un atributo opcional
como se muestra en la Figura 2.14.
Figura 2.14:
2.2.3 Dominio
Un dominio es el conjunto de todos los posibles valores que puede tomar un atributo. Los
elementos que hacen parte del conjunto de posibles valores comparten una estructura homogénea.
Los dominios pueden ser por intensión, aquellos que especifican el tipo de dato, o extensión,
aquellos que declaran cada elemento del conjunto de posibles valores. Por definición todos los
atributos simples están asociados a un dominio.
Ejemplo 2.7
En la Tabla 2.1 podemos observar 3 dominios declarados para describir los valores validos
que pueden tomar los atributos sexo, edad y notaFinal.
2.2 Componente Estático 27
Figura 2.15:
2.2.4 Relación
Una relación es una asociación, vínculo o correspondencia que existe entre entidades que
se relacionan de alguna manera el mundo real. La representación gráfica de una relación en el
modelo E/R se hace a través de un rombo, el nombre de la relación se pone dentro del rombo y
debe ser único. En caso de existir una relación que asocie una entidad débil y esta dependa de la
existencia de otra entidad, se debe expresar la relación con un rombo de doble línea. A través de
líneas se une el rombo a las entidades que se relacionan como se muestra en la Figura 2.16.
Figura 2.16:
Ejemplo 2.8
En la Figura 2.17 se establece la relación Nace entre las entidades PERSONA y PAÍS. Como
se puede observar la relación nace representa la asociación que existe en el mundo real entre las
dos entidades.
Figura 2.17:
Ejemplo 2.9
En la Figura 2.18 se establecen las relaciones diseña y fabrica entre las entidades EMPLEA-
DO y PRODUCTO. Las dos relaciones representan asociaciones que se dan en el mundo real
28 MODELO CONCEPTUAL: ENTIDAD INTERRELACIÓN
Figura 2.18:
Relaciones Binarias
En la Figura 2.21, se tiene un ejemplo de lo que se considera una interrelación binaria, en
la cual participan dos (2) entidades: PERSONA y VIVIENDA, indicando que üna PERSONA
habita en una VIVIENDA".
Relaciones Ternarias
En la Figura 2.22, se tiene un ejemplo de lo que se considera una interrelación ternaria , en
la cual participan tres (3) entidades.
Cardinalidad
Se considera como el número máximo y mínimo de ocurrencias de un tipo de Entidad que
pueden estar interrelacionadas con una ocurrencia del otro y otros tipos de Entidad que participan
en el tipo de interrelación. Las cardinalidades se notan con las siguientes etiquetas:
Ejemplo No. 1
La Figura 2.23 muestra un ejemplo en el cual dos tipos de entidad PERSONA y VIVIENDA
relacionados por medio de la interrelación Habita. La semántica de este modelo indica lo
siguiente: “una persona habita minimo una vivienda, máximo una vivienda, y una vivienda es
habitada mínimo por una persona máximo por muchas personas.” La correspondencia de esta
interrelacion es 1:N.
Ejemplo No. 2
En la Figura 2.24, se muestra un ejemplo en el cual existe una cardinalidad mínima de cero
(0), en el cual se relacionan dos tipos de entidad: MEDICO Y PACIENTE. La semantica de este
modelo indica lo siguiente: Ün medio puede atender minimo a 0 personas(en caso de que no
lleguen los pacientes) y maximo muchos pacientes, y un paciente es atendido por uno y solo un
medico.
Ejemplo No. 3
En algunos casos, es importante semánticamente conservar atributos en la interrelación, en
el ejemplo anterior, seria importante guardar el periodo en el cual la persona había la vivienda,
teniendo en cuenta lo anterior, se le agregaría dos atributos a la interrelación habita, de la
siguiente manera, como se ilustra en la Figura 2.25.
2.4 Mecanismos de Abstracción 31
2.4.1 Clasificación
En este mecanismo se hace la abstracción de lo común de un conjunto (general) de ejemplares,
identificando que características comparten, a partir de lo cual se crea una categoría a la cual
pertenecerán dichos ejemplares. La clasificación es considerada como la acción de abstraer
las características comunes a un conjunto de ejemplares para crear una categoría a la cual
pertenecen dichos ejemplares. Teoría de conjuntos (Intensión –Extensión). El mecanismo inverso
de abstracción es la Particularización. La particularización es pasar de la clase a sus ejemplares.
(Pertenencia).
En la Figura 2.26 se muestra en general como se representa el concepto de Clasificación.
Por ejemplo, se puede clasificar como vehículos a cualquier elemento que tenga mecanismos
de funcionamiento los cuales permitan desplazarse de una posición a otra. En este sentido se
puede considerar una clasificación de vehículo como se muestra en la Figura 2.27 en el cual se
puede visualizar claramente este mecanismo sobre el concepto de vehículo.
En este caso los ejemplares de una clase, presentan características similares, las cuales des-
criben la clase y dichas características toman valores concretos para cada uno de los ejemplares.
2.4.2 Generalización
Este mecanismo de abstracción busca identificar las características comunes a varias clases,
con el fin de construir una clase general, en la jerarquía que se forma se admite únicamente un solo
nivel, se considera una única superclase y las subclases necesarias que dependan directamente de
la superclase. El conjunto de ejemplares de una subclase “es un“ subconjunto de los ejemplares
de la correspondiente superclase. Todo ejemplar de una subclase, es también ejemplar de una
superclase. El mecanismo contrario se considera Especialización. En la Figura 2.28 se muestra
la forma general del concepto de Generalización.
Figura 2.29:
En el ejemplo anterior, un libro es editado por una universidad o por una editorial, pero no
por los dos a la vez.
Exclusión
Un Ejemplar de una entidad A unicamente puede relacionarse con un ejemplar de una entidad
B a travez de una interrelación I1 o U2, pero o ambas a la vez. A continuación, se presenta el
34 MODELO CONCEPTUAL: ENTIDAD INTERRELACIÓN
ejemplo de la restricción de exclusón, en la cual Todo ejemplar de profesor que este unido a un
ejemplar de curso mediante la interrelación imparte, no podrá estar unido al mismo ejemplar de
curso mediante la interrelación recibe.
Inclusividad
Una restricción de inclusividad se presenta cuando todo ejemplar de una entidad A que
participa en una interrelación I2 ha tenido que que participar previamente en la interrelación I1.
En el siguiente ejemplo, se muestra una restricción de inclusividad, en la cual un ingeniero para
ejecutar una obra, debe haber licitado la misma obra incialmente.
Inclusión
Se establece una restricción de inclusión, cuando todo ejemplar de una entidad A , para
participar en la asociación con un ejemplar de otra entidad B mediante una interrelación, es
necesario que ambos ejemplares esten asociados mdiante una segunda interrelación. En la Figura
2.33, se presenta un ejemplo en el cual todo ejemplar de persona que este unido a un ejemplar
de empleo, mediante la interrelación liquidada, tiene necesariamente que estar unido al mismo
ejemplar de empleo mediante la interrelación contratada.
2.5 Modelo Entidad Relación Extendido 35
2.5.2 Generalización
Totalidad: todo ejemplar del supertipo tiene que pertenecer a algún subtipo. El caso
contrario se llama parcialidad
Parcialidad: todo ejemplar del supertipo, tiene que pertenecer a algun sub-tipo.
Solapamiento: un mismo ejemplar del supertipo puede pertenecer a más de un subtipo.
El caso contrario se llama Exclusividad.
Exclusividad: todo ejemplar del supertipo, tiene que ertenecer a algún subtipo.
Restricciones de la generalización
Parcial exclusiva
Parcial solapada
Total exclusiva
Total solapada
A continuacion se presenta una generalización, en la cual participan las entidades persona,
empleado y estudiante. Esta restricción se considera total debido a que un ejemplar de la entidad
persona debe ser obligatoriamente un empleado o un estudiante y es solapada porque el ejemplar
puede ser empleado o administrador a la vez.
2.5.3 Agregación
El Modelo Entidad Relación no permite expresar relaciones entre relaciones o entre una
relacion y una entidad. Para esta restricción inherente el Modelo Entidad Relación Extendido
(MERE) permite crear una entidad agregada de nivel superior, la cual combina varias entidades
relacionadas mediante una relación. Es de gran utilidad cuando se desea relacionar una relación
con otras entidades. La representación gráfica de una agregación o entidad agregada se hace a
través de un rectángulo que envuelve las entidades y relación que deseamos asociar a través de
38 MODELO CONCEPTUAL: ENTIDAD INTERRELACIÓN
A continuación tenemos un esquema E/R que almacena la información de las audiciones que
organiza un empresario “Caza talentos” entre futuras estrellas de la música y algunas compañías
discográficas.
Se sabe que a partir de algunas audiciones se pueden generar grabaciones y las otras en las
que los cantantes no tuvieron un buen desempeño no generarán ninguna grabación. Esta situación
podría ser erróneamente modelada de la siguiente manera:
La solución planteada es errónea debido a que una relación ternaria indicaría que todas las
audiciones generan una grabación, lo cual no corresponde con la semántica del problema. Una
forma fácil de resolver este problema es definir una entidad agregada a partir Compañía,Cantante
y la relación Audición para relacionarla con la entidad Grabación.
2.5 Modelo Entidad Relación Extendido 39
3.1 INTRODUCCIÓN
La modelación entidad-relación. Como es bien conocido, se modelan situaciones reales que
La Normalización es un proceso mediante el cual un esquema de Base de Datos se lleva a un
nuevo esquema equivalente pero mejorado en términos de calidad de diseño. La calidad del diseño
la medimos con respecto a una serie de reglas que el esquema debe cumplir, dependiendo de las
reglas que cumple el esquema diremos que pertenece a cierta Forma Normal. La normalización
de datos consiste en la aplicación sucesiva de un conjunto de reglas y técnicas relacionadas con
la identificación de las relaciones que existen entre los atributos que conforman las relaciones de
una base de datos. Esto, con la intención de mejorar las condiciones generales de la base de datos:
no perder información, ser lo menos redundante posible, garantizar la integridad de los datos,
etc. El proceso de normalización debe llevar a un esquema desde su estado inicial hasta una
forma normal sin modificar las dependencias de los datos y por supuesto, sin perder información.
Existen distintas formas normales, unas más restrictivas que otras. En términos generales,
podemos concebir el conjunto de formas normales (etapas en el proceso de normalización), como
etapas incluyentes de la etapa anterior y cada vez más restrictivas y más eficientes. La siguiente
figura, muestra de manera esquemática la relación inclusiva de las formas normales que se basan
en dependencias funcionales.
podemos considerar los casos de relaciones binarias (entre dos entidades) con cardinalidades
opcionales y obligatorias del tipo 1:1, 1:N y N:M.
En este caso, se fusionan las dos entidades en una sola relación (o tabla) y su llave primaria
será cualquiera de las llaves de la Entidad 1 ó la de la Entidad 2. Como resultado de esto,
tendremos únicamente una tabla con todos los atributos.Cuando uno de los extremos de la
relación tiene opcionalidad (esto significa que la relación de un lado puede ser (0 ó 1).
En este caso, la llave primaria del lado de la Entidad 2 pasa a la Entidad 1 como llave foránea
y resultando 2 tablas.
Cuando ambos extremos de la relación son opcionales, (o sea que pueden o no existir las
conexiones, ser 0 ó 1).
3.2 TRANSFORMACIÓN DEL MODELO ENTIDAD-RELACIÓN (E-R) A MODELO
RELACIONAL 43
Figura 3.5: Representación de relación.
1). Cuando la cardinalidad del lado 1 es (1,1) o sea que la conexión es obligatoria.
En este caso, la relación entre las entidades, se convierte en una tabla que contendrá sus
propios atributos además de las llaves primarias de ambas entidades en los extremos de la
relación. Las llaves de las entidades 1 y 2 forman la llave primaria de la relación nueva y también
fungirán como llaves foráneas.
44 MODELO LÓGICO: RELACIONAL
Cuando se tiene una relación con cardinalidad N:M (o sea, del tipo muchos a muchos entre
entidades de los dos lados de la relación)
Entonces, deberá de resolverse convirtiendo la relación en una tabla que conserve sus
atributos y que además reciba las llaves primarias de las entidades de los lados como llaves
foráneas y primarias también.
3.3 NORMALIZACIÓN
3.3.1 Relación
Una relación en el modelo relacional, es un objeto, persona o un hecho sobre el cual, es nece-
sario conservar información. Esto se debe a que su información será consultada posteriormente.
Las relaciones se constituyen de ciertos elementos que pueden verse en la siguiente figura:
3.3 NORMALIZACIÓN 45
Cada atributo está definido en un cierto dominio. Los dominios de los atributos deben ser
simples. El conjunto de dominios de todos los atributos (d1, d2, . . . , dn) conforma el dominio
de la relación D. La relación tiene una cabecera formada por pares (atributo, dominio). Por
ejemplo: el atributo ciudad está definido en el conjunto de nombres de ciudades. Las bases de
datos relacionales deben permitir el uso de dominios para los atributos. Sin embargo, un concepto
que se asemeja a un dominio es un tipo de dato y es normalmente la manera de subsanar este
punto. Una relación tiene también un cuerpo. Éste, se forma por pares del tipo (atributo, valor).
Cada tupla contiene valores para los distintos atributos de la relación. Los valores de los atributos
pueden ser nulos a menos que el atributo o atributos sean parte de la llave primaria de la relación.
Para las llaves foráneas las reglas son menos restrictivas siempre u cuando se consideren todas
las implicaciones de asignar valores nulos. Las relaciones cuentan con un atributo o conjunto
de atributos que identifican de manera única y mínima cada tupla de la misma. Este atributo o
conjunto de atributos son la llave primaria de la relación. El total de tuplas de una relación se
denomina cardinalidad de la relación y es una característica muy cambiante. Al total de atributos,
se le denomina grado y esta es una característica más permanente a lo largo del tiempo. Un
atributo es un elemento que sirve para describir o caracterizar a cada tupla de una relación. Por
ejemplo: La relación Alumno:
Considerando la relación R:
3.3 NORMALIZACIÓN 49
Dentro del conjunto de las superllaves, existen otras llaves (más restrictivas) que resultan de
interés primordial en la normalización de bases de datos, pues las primeras formas normales,
dependen de la llave primaria de las relaciones.
50 MODELO LÓGICO: RELACIONAL
En la Figura 3.13, se puede ver la relación que guardan las llaves de una relación.
El conjunto C corresponde con todas las superllaves que una relación puede tener. El conjunto B,
se constituye por todas las llaves candidato de R (todos los atributos o conjuntos de atributos que
pueden formar una llave primaria).
Una llave primaria se forma por el atributo o conjunto de atributos que identifican de forma única
y mínima a cada tupla de una relación.
Nótese que ahora no es suficiente con identificar de forma única cada tupla, sino que además
debe ser un atributo o combinación de atributos mínima. Retomaremos la relación R.
Se satisface calle → ciudad-cliente pero es posible en el mundo real que ciudades diferentes
tengan calles con el mismo nombre, por lo que no conviene incluirla en el conjunto de DF
(dependencias funcionales).
Podemos tener dependencias transitivas, si éstas se transmiten de un atributo a otro. Por ejemplo:
A → B y B→C entonces A→C a través de B.Tenemos dependencias completas y parciales
por ejemplo: AB→CB→C. La dependencia B→C es completa porque no puedo quitar ningún
atributo del lado izquierdo de la dependencia (conocido como determinante), sin que se pierda la
dependencia.
Pero AB→C es parcial si yo sé que B→C porque puedo omitir a A del lado izquierdo de la
dependencia y se sigue cumpliendo.
Para diseñar una B.D relacional, primero se debe generar una lista de todas las dependencias
funcionales que existan en el mundo real y para esto utilizamos la teoría de las dependencias
funcionales:
Sea F el conjunto de DF (dependencias funcionales), el conjunto cerrado de F, (F+)
contiene todas las dependencias funcionales que F implica.
Para calcular F+, existen 3 reglas de inferencia y 3 axiomas que se complementan para
conocer todas las dependencias existentes en un esquema de bases de datos.
Para simplificar la aplicación de los axiomas se tiene las siguientes reglas adicionales:
Ejemplo 3.1
Si se tiene un esquema R=(A, B, C, G, H, I) y un conjunto de dependencias:
52 MODELO LÓGICO: RELACIONAL
Se puede obtener
En muchas ocasiones se procura encontrar aquellos atributos que son determinados por un
conjunto dado de atributos.
Sea X un conjunto de atributos, al conjunto de todos los atributos determinados funcionalmen-
te por X bajo un conjunto F de dependencias funcionales se le conoce como CONJUNTO
CERRADO DE X y se denota por X+
Ejemplo:
Si se tiene el mismo esquema anterior: R=(A,B,C,G,H,I) y el conjunto de dependencias:
A→B
A→C
CG →H
CG →I
B →H
Calcular AG+
Empezamos con:
Resultado = A,G
Como A→B ∧ A ⊆ Resultado, entonces Resultado=Resultado U B = A, G, B
Como A→C ∧ A ⊆ Resultado, entonces Resultado=Resultado U C = A, G, B, C
3.3 NORMALIZACIÓN 53
Formas normales
1NF. Primera Forma Normal.
Una Relación está en 1NF si todos los dominios de sus atributos son escalares, es decir: los
atributos deben ser simples (no compuesto) e indivisibles. Esto descarta:
- Grupos repetitivos - Campos compuestos en los cuáles se pueda tener acceso individual a sus
componentes, por ejemplo fechas (dd/mm/aa) o total
2NF. Segunda Forma Normal.
Una relación está en 2NF si - Está en 1NF y - Todos los atributos no-llave, dependen completa-
mente de la llave, dicho de otro modo, si no dependen parcialmente de la llave.
Regla para conseguir el 2NF: Eliminar los atributos no dependientes completamente de la llave y
ponerlos en otra tabla estableciendo una relación.
Cada columna debe tener un nombre único, el orden de las columnas en la tabla no es
importante.
Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de
las filas no es importante. Por lo general la mayoría de las relaciones cumplen con estas
características, así que podemos decir que la mayoría de las relaciones se encuentran en la
primera forma normal.
Para ejemplificar como se representan gráficamente las relaciones en primera forma normal
consideremos la relación alumno cursa materia cuyo diagrama E-R es el siguiente:
Como esta relación maneja valores atómicos, es decir un solo valor por cada uno de los campos
que conforman a los atributos de las entidades, ya se encuentra en primera forma normal,
gráficamente así representamos a las relaciones en 1FN.
Por ejemplo, si para alguna Base de Datos, su esquema contiene una relación como la siguiente:
Solucion 2: Si r(R) es una relacion que viola 1NF, N el atributo que produce el problema y
K la clave primaria de .
3.3 NORMALIZACIÓN 55
Crear una nueva relacion r0 (R) a partir de remover el atributo N de r(R) y agregar un
atributo N 0 de tal manera que las tuplas cumplan:
Para indicar que un empleado trabaja cierto número de horas en cierto proyecto, cada
proyecto se ubica en un único lugar y tiene un nombre y código. Claramente la única clave
56 MODELO LÓGICO: RELACIONAL
Para entender la idea de 2NF veremos inicialmente un caso particular simple en donde queda
claro su aplicación. Supondremos que todas las relaciones tienen una única llave candidata lo
que quiere decir que las llaves primarias se encuentran definidas. Un esquema de Base de Datos
con la anterior característica se encuentra en 2NF si esta en 1NF y toda relación r(R) con llave
primaria K cumple que para cualquier atributo A que no sea parte de la llave primaria, A es
totalmente funcionalmente dependiente de K.
Nótese que si la llave primaria de una relación está compuesta por solo un atributo, la
propiedad se cumple siempre.
Un esquema con la relación empleado-proyecto de la Tabla 3.7 no se encuentra en 2NF ya
que nom_emp, nom_proy y lugar_proy dependen funcionalmente en forma parcial de la llave
primaria.
Solución: Primero convertir en 1NF. Sea r(R) una relacion que viola 2NF, y K la llave primaria
de r(R).
Identificar un conjunto de atributos A que depende funcionalmente en forma parcial de K, y el
subconjunto de K 0 ⊂ K del que depende funcionalmente en forma total.
Crear una nueva relación r0 (R0 ) que resulta de r(R) al eliminar el conjunto de atributos A.
Crear una nueva relación t(K’,A) de tal manera que las tuplas cumplan: t[A]=r[A] ⇔
[K’]=r[K’]
La llave primaria de t(K’,A) es K’.
Eliminar la relación r(R) del esquema.A pesar de que t(K’,A) esta en 2NF, r’(R’) posi-
blemente aun no se encuentra en 2NF, por lo que se debe repetir el proceso hasta que el
esquema este en 2NF.
3.3 NORMALIZACIÓN 57
En la anterior formulación las relaciones tenían una única llave candidata y por lo tanto la
llave primaria estaba fija. En general este supuesto puede ser no cierto y entonces 2NF cambian
en parte su formulación: Un esquema de Base de Datos se encuentra en 2NF si esta en 1NF y en
toda relación r(R) si un atributo A no es parte de ninguna llave candidata de R, entonces A es
totalmente funcionalmente dependiente de todas las llaves candidatas de R. Es simplemente una
generalización del caso anterior pero ahora tomando en cuenta todas las llaves candidatas (no
solo la primaria).La solución es similar a la anterior salvo que se toman en cuenta en total las
llaves candidatas, no solo las llaves primarias. Informalmente:
Eliminar de la relación inicial los atributos que dependen de forma parcial de parte de una
llave candidata.
Crear una nueva relación con la parte de la llave candidata (como llave primaria) y los
atributos asociados.
Por ejemplo, supongamos el siguiente esquema para la relación lote:
EJERCICIO ADICIONAL
A continuación se presenta un ejemplo completo:
Tenemos una empresa pública donde los puestos de trabajo están regulados por el Estado, de
modo que las condiciones salariales están determinadas por el puesto. Se ha creado el siguiente
esquema relacional EMPLEADOS (nss, nombre, puesto, salario, emails) con nss como clave
primaria.
que sólo varían en que cada una de ellas guarda uno de los valores que había en M.
La clave primaria de R’ es (K, M’), dado que podrá haber valores de K repetidos, para los
valores multivaluados en M. Siguiendo el ejemplo, tendríamos el siguiente esquema para
la nueva tabla EMPLEADOS’(a) con clave primaria (nss, email):
Solución 2: separar el atributo que viola 1FN en una tabla. En general, esta solución pasa
por:
Sustituir R por una nueva relación modificada R’ que no contiene el atributo M.
Crear una nueva relación N(K, M’), es decir, una relación con una clave ajena K referen-
ciando R’, junto al atributo M’, que es la variante mono-valuada del atributo M.
La nueva relación N tiene como clave (K, M’).
Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEA-
DOS’(b). Y además tendríamos una nueva tabla EMAILS con clave primaria (nss, email):
Todos sus atributos que no son de la clave principal tienen dependencia funcional completa
respecto de todas las claves existentes en el esquema. En otras palabras, para determinar
cada atributo no clave se necesita la clave primaria completa, no vale con una subclave.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más
atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo),
entonces también está en 2FN.Por tanto, de las soluciones anteriores, la tabla EMPLEADOS’(b)
está en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el esquema está en 2FN.
Sin embargo, tenemos que examinar las dependencias funcionales de los atributos no clave de
EMPLEADOS’(a). Las dependencias funcionales que tenemos son las siguientes:
nss→ nombre, salario, email
puesto→ salario
Como la clave es (nss, email), las dependencias de nombre, salario y emailson incompletas,
por lo que la relación no está en 2FN.En general, tendremos que observar los atributos no clave
que dependan de parte de la clave.Para solucionar este problema, tenemos que hacer lo siguiente
para los grupos de atributos con dependencia incompleta M:
Eliminar de R el atributo M .
Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que
depende, que
llamaremos K’ .
La clave primaria de la nueva relación será K’ .
Siguiendo el ejemplo anterior, crearíamos una nueva relación con los atributos que tienen
dependencia incompleta y al eliminar de la tabla original estos atributos nos quedaría:
Como vemos, la solución a la que llegamos es la misma que en la otra opción de solución
para el problema de 1FN.
Tercera forma normal (3FN) Una relación está en tercera forma normal si, y sólo si:
Está en 2FN
62 MODELO LÓGICO: RELACIONAL
Y, además, cada atributo que no está incluido en la clave primaria no depende transitiva-
mente de la clave primaria.
Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales
entre atributos que no estén en la clave. En general, tenemos que buscar dependencias transitivas
de la clave, es decir, secuencias de dependencias como la siguiente: K→A y A→B, donde A
y B no pertenecen a la clave. La solución a este tipo de dependencias está en separar en una
tabla adicional N el/los atributos B, y poner como clave primaria de N el atributo que define la
transitividad A.
Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:
nss→puesto puesto→ salario
Por lo tanto la descomposición sería la siguiente:
En la nueva tabla PUESTOS, la clave sería el puesto, que también queda como clave ajena
referenciando la tabla EMPLEADOS. El resto de las tablas quedan como estaban.
EVALUACION
Ejercicio 1:
Dada la siguiente relación PRÉSTAMO_LIBROS (Colegio, Profesor Infantil, Asignatura_Habilidades,
Aula, Curso, Libro, Editorial, Fecha_Préstamo) que contiene información relativa a los présta-
mos que realizan las editoriales a los profesores de primaria de los colegios para su evaluación
en alguna de las asignaturas/habilidades que imparten.
3.3 NORMALIZACIÓN 63
Se pide responder a los siguientes apartados, considerando las tuplas relación PRÉSTA-
MO_LIBRO mostradas en la tabla anterior, que a un profesor no se le puede prestar más de un
libro de la misma editorial en el mismo día y que a un profesor no se le puede prestar más de una
vez un mismo libro:
a) Indicar las dependencias funcionales utilizando las siguientes abreviaturas: Colegio (C), Pro-
fesorInfantil (P), Asignatura_Habilidades (H), Aula (A), Curso (Cu), Libro (L), Editorial (E) y
Fecha_Préstamo (F)
b) ¿Cuáles son sus claves? ¿Cuáles son los atributos principales? ¿Y los atributos no principales?
c) ¿En qué forma normal se encuentra la relación? Explicar por qué.
Ejercicio 2: Dada la relación GASTOS_EMPLEADO(Cod_empleado, Cod_viaje, Destino, Gas-
to_total) en la que se cumplen las siguientes dependencias funcionales:
Cod_empleado → Gasto_total Cod_viaje → Destino
Se pide:
a) ¿En qué Forma Normal se encuentra la relación? ¿Por qué?
b) En caso de que la relación no esté en FNBC, ¿cuáles son los problemas que tiene la relación
GASTOS_EMPLEADO?
4 — CAPITULO IV - MODELO
FÍSICO
Ejemplo 4.1.
Consideramos la relación Persona (id, nombre, sexo, edad) que se muestra en la Tabla 4.1.
Supongamos que se requiere consultar los datos de las personas que tienen una edad mayor a
18 años, en algebra relacional usando el operador de selección podemos describir esta consulta
como
Ejemplo 4.2
El predicado o restricción del operador de Selección puede incluir una combinación de
condiciones sobre los atributos de la relación. Por ejemplo, si necesitamos consultar las personas
de sexo masculino (M) que tengan menos de 25 años. En algebra relación debemos expresar esta
consulta como
Ejemplo 4.3
Consideremos la Relación Matricula de la Tabla 4.4. Se requiere consultar todos los es-
tudiantes que tengan una nota mayor igual a 3.0. En algebra relacional podemos expresarlo
como
En la relación que resulta en la Tabla 4.5, se puede observar que la tupla con los datos de
“Lucia Jiménez” de la relación original no se ha tenido en cuenta en el resultado, esto debido a
que la comparación realizada en el operador de Selección se ha hecho sobre un atributo que para
esta tupla contiene un valor nulo o vacío.
Ejemplo 4.4
Consideremos la Relación Matricula de la Tabla 4.4. Se requiere consultar todos los estu-
diantes que tengan una edad mayor a la de su profesor. En algebra relacional podemos expresarlo
como:
Operación de Proyección
La operación Proyección permite definir un subconjunto de campos de una relación que
serán mostrados en la consulta resultante. El operador recibe una relación R de n campos y el
resultado de la proyección es una nueva relación con m campos, siendo m<=n.
Ejemplo 4.5
Consideremos la relación Entrevista de la Tabla 4.7. Se requiere consultar solo los nombres
de los profesores que han practicado pruebas a los estudiantes. En algebra relación podemos
expresarlo como
En la relación que resulta en la Tabla 4.8, podemos observar que la operación elimina todas
las filas duplicadas, ya que al revisar los datos de la tabla original nos damos cuenta que en el
atributo profesor “Jaime Falla” se encuentra en 3 tuplas, sin embargo, la operación por ser una
operación de conjuntos solo lo muestra en el resultado una vez.
Como ya se ha visto, el resultado de una operación de algebra relacional genera una nueva
relación. Por lo tanto, al resultado de una operación se le puede aplicar otra operación. Esto nos
permite implementar consultas más complejas.
Ejemplo 4.6
Operación de Renombramiento
La operación de Renombramiento se aplica sobre una relación R que puede ser el resultado
de una operación de algebra relacional. Esta operación es útil ya que las expresiones de algebra
relacional no tienen un nombre para referirse a ellas.
Ejemplo 4.7
Consideremos la relación que resulta en la Tabla 4.11. Se desea asignar un nombre a la
relación resultante de la expresión de algebra relacional, de tal manera que le nombre sea
“PaisesGrandes” y sus atributos sean: id, Nombre y Extensión. Esto en algebra relacional
podemos expresarlo como
Ejemplo 4.8
Considere las relaciones Estudiante y Docente de la Tabla 4.12. Se requiere obtener los datos
de estudiantes y docentes en una nueva relación. En algebra relacional podemos expresar esta
consulta como
El resultado de esta consulta podemos observarlo en la Tabla 4.13. Las tuplas de ambas
relaciones han sido unidas en una nueva relación, por ser una operación de conjuntos, las tuplas
repetidas se han eliminado y solo aparecen en la nueva relación una vez.
Ejemplo 4.9
Considere las relaciones Estudiante y Docente de la Tabla 4.12. Se desea consultar solos los
nombres de estudiantes y docentes. En algebra relacional podemos expresar la consulta como
Operación de Diferencia
La operación Diferencia permite crear una nueva relación con los elementos de la relación
R1 que no están en la relación R2. Para que la operación sea válida, las relaciones R1 y R2 deben
ser compatibles.
Ejemplo 4.10
Considere las relaciones Estudiante y Docente de la Tabla 4.12. Se desea obtener los Estu-
diantes que no han sido registrados como docentes. En algebra relacional podemos expresarlo
como los estudiantes que no están en la relación , empleando la operación diferencia se representa
como
Operación de Intersección
La operación Intersección es una operación básica de conjuntos que permite crear una nueva
relación con los elementos que se encuentran en una relación R1 y una relación R2.
Considere las relaciones Estudiante y Docente de la Tabla 4.12. Se desea conocer los
estudiantes que también son docentes. En algebra relacional podemos expresarlo como la
intersección de las relaciones Estudiante y Docente.
Cuando se realiza una operación de producto cartesiano entre dos relaciones R1 y R2 con
atributos con el mismo nombre o que tienen el mismo significado se puede extraer información.
Ejemplo 4.12
Considere las relaciones Empleado y Departamento de la Tabla 4.18, ambas relaciones tienen
un atributo con el nombre deptoid, en la relación Empleado el atributo deptoid representa el id
del departamento al que pertenece un empleado mientras que en la relación Departamento el
atributo representa el id de cada departamento registrado.
De la Tabla 4.20 se puede observar que existen algunas filas en las que la columna Emplea-
do.deptoid toma los mismos valores que la columna Departamento.deptoid. Si consideramos que
el atributo deptoid en la relación de Empleado representa el id del departamento al que pertenece
el empleado, se puede concluir que a través del atributo deptoid de la relación Departamento
se accede al nombre del departamento en el que trabaja el empleado si los valores de deptoid
coinciden en Empleado y Departamento.
4.1 ÁLGEBRA RELACIONAL 73
De esta manera, si se desea consultar los datos de empleados y departamentos a los que
pertenecen se deberá aplicar una selección sobre el resultado del producto cartesiano entre las
relaciones Empleado y Departamento para filtrar las filas en las que Empleado.deptoid sea igual
a Departamento.deptoid. En algebra relacional esto es
Operación División
La operación División se aplica sobre dos relaciones R y S cuando se desea realizar una
consulta a partir de la expresión “para todos”.
Ejemplo 4.13
Considere las relaciones Asignatura y Matricula de las Tablas 4.23 y 4.24, la relación
Matricula almacena el id del estudiante y el id de la asignatura matriculada. Se desea consultar
los id de los estudiantes que han matriculado todas las asignaturas. En algebra relacional podemos
expresarlo como la división entre la relación Matricula y una relación que contenga los id de
todas las asignaturas. Es importante aclarar que la división se calcula con una relación que
74 CAPITULO IV - MODELO FÍSICO
El resultado de esta consulta podemos observarlo en la Tabla 4.25. Solo son mostradas la
tuplas de la relación Matricula que tienen correspondencia con la combinación de todas las
tuplas de Asignatura.
Ejemplo 4.14
Considere las relaciones Persona y País de la Tabla 4.27, ambas relaciones tienen un atributo
con el nombre pai_id, el atributo pai_id en la relación Persona representa el id del país de
nacimiento de las personas registradas. Se desea consultar los datos de las personas junto al
nombre de su país de nacimiento. En algebra relacional podemos expresarlo a través de un
producto cartesiano entre Persona y País, y posteriormente aplicar sobre este resultado una
operación de selección para filtrar solo las tuplas en donde hay correspondencia entre los
atributos en común:
Una operación de Combinación Natural solo retorna las tuplas que cumplen con la condición
encargada de validar que los atributos en común de ambas relaciones tengan el mismo el valor,
mientras que una Combinación Externa considera algunas tuplas que no cumplen la condición.
Para dichas tuplas de una relación que no encuentran correspondencia con la otra relación, se
completa el resultado con valores nulos.
Existen tres tipos de Combinación Externa:
Ejemplo 4.15
Considere las relaciones Docente y Universidad de la Tabla 4.30. La relación Docente tiene
el atributo uni_id que representa el id de la Universidad a la cual pertenece. Se desea consultar
los datos de los docentes y en caso de pertenecer a una universidad también se debe mostrar el
nombre de la Universidad. En algebra relacional podemos expresarlo como una combinación
externa a la izquierda entre Docente y Universidad.
Ejemplo 4.16
Considere las relaciones Docente y Universidad de la Tabla 4.30. Al aplicar una combinación
externa a la derecha entre Docente y Universidad el resultado incluirá las tuplas de Universidad
que encuentren correspondencia con Docente más las tuplas de Universidad (la relación de la
derecha) que no encuentren correspondencia con Docente:
Ejemplo 4.17
78 CAPITULO IV - MODELO FÍSICO
Considere las relaciones Docente y Universidad de la Tabla 4.30. Al aplicar una combinación
externa completa entre Docente y Universidad el resultado incluirá las tuplas de Universidad que
encuentren correspondencia con Docente más las tuplas de Docente (la relación de la izquierda)
que no encuentren correspondencia con Universidad y las tuplas Universidad (la relación de la
derecha) que no encuentren correspondencia con Docente:
Las operaciones de agregación son empleadas para obtener resúmenes de los datos de una
relación. El resultado de una operación de agregación retorna un único valor y para su cálculo no
considera los valores nulos.
Existen cinco tipos de funciones de agregación: COUNT, AVG, MAX, MIN y SUM.
COUNT:
Ejemplo 4.18
Considere la relación Empleado de la Tabla 4.34. Se desea calcular la cantidad de salarios
registrados. En algebra relacional podemos expresarlo como:
SUM
Retorna la suma de los valores en el atributo indicado sin considerar valores nulos.
Ejemplo 4.19
Considere la relación Empleado de la Tabla 4.33. Se desea calcular el valor total de los
salarios registrados. En algebra relacional podemos expresarlo como:
AVG
Retorna la media de los valores en el atributo indicado sin considerar valores nulos.
Ejemplo 4.18
Considere la relación Empleado de la Tabla 4.34. Se desea calcular el promedio de los
salarios registrados. En algebra relacional podemos expresarlo como:
MIN
Retorna el dato más pequeño de los valores en el atributo indicado sin considerar valores
nulos.
80 CAPITULO IV - MODELO FÍSICO
Ejemplo 4.21
Considere la relación Empleado de la Tabla 4.34. Se desea calcular el menor salario
registrado. En algebra relacional podemos expresarlo como:
El resultado de esta consulta podemos observarlo en la Tabla 4.38. La consulta retorna el dato
más pequeño de los valores no nulos registrados en el atributo Salario de la relación Empleado.
MAX
Retorna el dato más grande de los valores en el atributo indicado sin considerar valores nulos.
Ejemplo 4.22
Considere la relación Empleado de la Tabla 4.34. Se desea calcular el mayor salario
registrado. En algebra relacional podemos expresarlo como:
El resultado de esta consulta podemos observarlo en la Tabla 4.39. La consulta retorna el dato
más grande de los valores no nulos registrados en el atributo Salario de la relación Empleado.
Ejemplo 4.23
Considere la relación Empleado de la Tabla 4.33. Se desea calcular la cantidad de departa-
mentos distintos registrados. En algebra relacional podemos expresarlo como:
COUNT (*)
La operación de agregación COUNTpuede tomar comoargumento un * en lugar de un atri-
buto, esto indica que se calculará el conteo de todas las tuplas de la relación.
Ejemplo 4.24
Considere la relación Empleado de la Tabla 4.33. Se desea calcular la cantidad de empleados
registrados. En algebra relacional podemos expresarlo como:
cantidad INT(4),
total INT(4)
)
2. Restricción de Unicidad. La restricción UNIQUE obliga a que el contenido de una o
más columnas no puedan repetir valores. la forma general para colocar esta restricción es la
siguiente:
CREATE TABLE cliente(dni VARCHAR2(9) UNIQUE);
en el siguiente ejemplo, en la cración de la tabla pedidos, se incluye una restrición de unicidad.
Create Table pedidos ( id_pedido INT(4) NOT NULL UNIQUE, id_cliente INT(4) NOT NULL,
id_articulo INT(4)NOT NULL, fecha DATE, cantidad INT(4), total INT(4) )
La instrucción ALTER TABLE permite hacer cambios en la estructura de una tabla. por
ejeplo añadir o borrar columnas, cambiar el tipo de columnas existentes o renombrar una columna.
con este tipo de instruccion, se pueden realiza las siguientes operaciones de modificacion:
Para borrar una columna de una tabla, la forma general de la instruccion es la siguiente:
Siguiendo con elejemplo de la tabla pedido, si se requiere cambiar el nombre del campo cantidad
por numero_elementos, se realizaria de la siguiente manera:
4.3.1 Consultas
SQL provee algunos constructos que permiten imitar el comportamiento del Algebra Rela-
cional (AR) para obtener información desde tablas, vistas o combinaciones de ambas. En esta
sección se iniciará con la descripción de expresiones de consulta sencillas y se irá incrementando
el nivel de complejidad a medida que se avanza en el tema. Además presenta las equivalencias
entre las funciones del algebra relacional y los constructos SQL.
Consulta Básica
El formato más simple de la expresión de consulta en SQL es el siguiente:
Aclaración: para interpretar la sintaxis de las expresiones en esta sección es necesario indi-
car:
- Los corchetes “[]” indican que lo que se encuentre entre ellos es opcional
- El carácter pipe “|” se puede leer como “o”, es decir que puede ir uno u otro elemento
- Las llaves “{}” indican inicio y fin de una expresion
- La expresión “[. . . ]” indica que el elemento o conjunto de elementos anterior a ella se puede
repetir indefinidamente
Se utiliza cuando se necesita obtener la información del total de columnas de la tabla o vista
incluida en la cláusula FROM. La sentencia SQL para obtener todos los datos de todas las
columnas de la tabla Productos será:
86 CAPITULO IV - MODELO FÍSICO
El equivalente en AR para el resultado del anterior código SQL incluiría solamente el nombre
de la relación sin operador alguno, que debería presentar todas las columnas y tuplas que esta
contiene.
Como se observó en algebra relacional es posible que de una relación se necesiten obtener
sólo un conjunto determinado de columnas, para ello la sentencia de consulta SQL permite
especificar cuáles de las columnas se desean desplegar en los resultados. Adicionando esta
posibilidad la sintaxis de la consulta ahora es:
En caso que se deseen obtener solamente algunas de las columnas de la tabla Producto, se
puede hacer uso de la sentencia indicando explícitamente cuales de las columnas se quieren
desplegar, por ejemplo:
Cabe resaltar que el orden de las columnas en el resultado depende del orden establecido en
la sentencia de consulta y no en el orden de las columnas en las tablas.
4.3 STRUCTURED QUERY LANGUAGE (SQL) - DATA MANIPULATION LANGUAGE
(DML) 87
Renombramiento de columnas
La sentencia de consulta permite establecerle un Alias a cada una de las columnas desple-
gadas mediante la palabra reservada AS, esto hará que en el resultado en lugar del nombre de
la columna aparezca el alias establecido. Si el alias está compuesto por una única palabra se
puede colocar sin comillas simples (‘), en otro caso (más de una palabra), éstas son obligatorias.
En la siguiente sentencia por ejemplo se establecen alias a dos de las tres columnas de la tabla
Productos:
Filtros a Consultas
Uno de los operadores mas utilizados del algebra relacional es la “Selección”, cuya funciona-
lidad es imitada por la cláusula WHERE dentro del constructo de consulta en SQL, si se adiciona
dicha cláusula la sintaxis de la consulta en SQL queda de la siguiente forma:
- Mayor (>): retorna verdadero sólo cuando el primer operando es mayor que el segundo
- Menor(<): retorna verdadero sólo cuando el primer operando es menor que el segundo
- Mayor o igual (>=): retorna verdadero cuando el primer operando es mayor o igual que el
segundo
- Menor o igual (<=):retorna verdadero cuando el primer operando es menor o igual que el
segundo
Las operaciones lógicas pueden anidarse un número ilimitado de veces mediante el uso de
paréntesis, lo que permite crear lógicas booleanas muy complejas si se requieren.
Retomando el ejemplo con la tabla productos, podemos construir una sentencia que retor-
ne solamente los productos con identificador mayor que 301, la consulta SQL sólo necesitará
una sola condición como la siguiente:
SELECT *
FROM Productos
WHERE Identificador > 301
El equivalente en AR es el siguiente:
Para los siguientes ejemplos se asumirá que la siguiente base de datos para un sistema que
facilita el registro de compras en un almacén de abarrotes:
En las bases de datos relacionales es muy importante poder operar relaciones para obtener
información en las consultas.
Para las operaciones básicas y extendidas del Algebra Relacional que permiten operaciones entre
dos o más relaciones existen sus equivalentes en SQL, a continuación se harán explicitas esas
equivalencias.
Producto Cartesiano
El soporte al producto cartesiano en SQL hace que la sintaxis del constructo de consulta se
expanda para quedar de la siguiente forma:
Se debe notar que en esta sintaxis a cada nombre_columna es opcional anteponerle el nombre
de la tabla o vista de donde se extrae, esto porque puede suceder que en las tablas o vistas
incluidas en el producto cartesiano exista más de una columna con el mismo nombre, lo que
implica que se debe especificar de cual tabla o vista se extrae la información. En caso que
el nombre de la columna sea único en todas las tablas y vistas involucradas en el producto
no es necesario indicar de donde se extrae la información. Ocurre una situación similar en la
condición de la sección WHERE, en donde será opcional incluir el nombre de la vista o ta-
bla de donde se extrae la columna para evaluar la condición, la sintaxis de la condición ahora será:
{ [{tabla|vista}.]nombre_columna | Constante }
{Comparador} { [{tabla|vista}.]nombre_columna | Constante}
[{Operador_lógico} {condicion} ] [. . . ]
Por ejemplo, la siguiente consulta extrae todas las columnas resultado del producto cartesiano de
las tablas Clientes y Productos:
Para las operaciones que involucran una sola tabla de ambos lados del operador y para
mejorar la legibilidad de la consulta es posible establecerle un Alias a la tabla o vista, el cual
deberá ser utilizado para nombrar a las columnas tanto en la sección SELECT como en la
condición en el WHERE. La sintaxis con este nuevo elemento queda así:
La siguiente consulta presenta los nombres de clientes y productos extraídos de la operación pro-
ducto cartesiano entre la selección de clientes con Código menor o igual que 701 y la selección
de productos con identificador mayor que 301. Se utilizan Alias para renombrar las tablas los
cuales deben ser antepuestos tanto en la sección SELECT como en el WHERE.
Unión
En SQL el operador Unión del algebra relacional funciona a nivel de consultas, la sintaxis
del operador es:
Para que dos sentencias de consulta puedan operarse mediante la diferencia es necesario cumplir
las mismas condiciones requeridas por el operador UNION.
El siguiente ejemplo SQL presenta los Identificadores de los productos que no están en la
tabla Compras
SELECT Identificador
FROM PRODUTO
MINUS
SELECT IdentificadorProducto AS Identificador
FROM Compras
Intersección
El constructo de consulta provisto por SQL también soporta Intersección entre consultas, la
sintaxis es la siguiente:
Sentencia_Consulta INTERSECT Sentencia_Consulta
Al igual que los operadores de unión y diferencia las sentencias involucradas deben tener igual
número de columnas y compatibilidad uno a uno en tipos de datos.
El siguiente ejemplo SQL presenta los identificadores de productos registrados tanto en la tabla
Compras como en la tabla Productos:
SELECT Identificador
FROM PRODUTO
INTERSECT
SELECT IdentificadorProducto AS Identificador
FROM Compras
Unión Natural
Una de las funciones más útiles en SQL es la Unión en sus diferentes versiones, Natural,
Completa, “Por Derecha”, “Por Izquierda” e “Interna”. La Unión Natural combina la proyección,
selección y producto cartesiano en una sola operación, adiciona una condición implícita a la
operación igualando la llave primaria a la llave foránea (debe existir una restricción del tipo
llave foránea –ForeignKey- entre las tablas operadas), y en la proyección elimina la columna, el
soporte a esta función hace que la sintaxis de la consulta SQL quede de la siguiente forma:
SELECT {* |
{[{tabla|vista|alias}.]{nombre_columna} [as nombre_presentar1]
[,[{tabla|vista|alias}.]{nombre_columna} [as nombre_presentar2]] [. . . ] }}
FROM {tabla | vista} [alias] [, {tabla | vista} [alias]] [. . . ]
[NATURAL JOIN {tablaN | vista} [alias]][. . . ]
[WHERE condición]
La siguiente consulta SQL presenta el nombre de los productos, fecha de compra, identifi-
cadores de productos y cantidad comprada por cada uno de los clientes.
En el siguiente ejemplo SQL se hace una Unión por la Izquierda entre Productos y Com-
pras, lo que garantiza que se desplieguen todos los productos independientemente que estén
relacionados o no en la tabla Compras. Se extrae nombre del producto, identificador, fecha y
hora de compra y cantidad comprada.
En el siguiente ejemplo se realiza una Unión por la Derecha entre Compras y Clientes lo que
hace que se presenten todos los clientes independientemente de si están o no relacionados con
alguna tupla de la tabla Compras:
Igual que en álgebra relacional, en SQL, el resultado de las operaciones con LEFT JOIN y
RIGTH JOIN depende de la posición de los operandos. Ambos operadores presentan el total de
registros de la tabla o vista a la izquierda o derecha respectivamente sin importar si la existe un
registro relacionado en la otra tabla o vista operada.
96 CAPITULO IV - MODELO FÍSICO
Unión Completa
La Unión Completa expande aún más la sintaxis de la consulta quedando de la siguiente
forma:
SELECT {* |
{[{tabla|vista|alias}.]{nombre_columna} [as nombre_presentar1]
[,[{tabla|vista|alias}.]{nombre_columna} [as nombre_presentar2]] [. . . ] }}
FROM {tabla | vista} [alias] [, {tabla | vista} [alias]] [. . . ]
[NATURAL JOIN {tabla | vista} [alias]] [. . . ]
[{LEFT | RIGHT | FULL} JOIN {tabla | vista} [alias]
ON condición] [. . . ]
[WHERE condición]
En el siguiente ejemplo SQL se hace uso de la unión completa para extraer toda la infor-
mación de la base de datos de ejemplo uniendo las tres tablas y garantizando que se presente toda
la información de las tablas productos y clientes aunque no estén relacionadas en la tabla compras.
Cabe anotar que el siguiente ejemplo de unión completa utiliza la notación de ORACLE, no se
garantiza su fucionamiento en otros motores de bases de datos.
Unión Interna
La Unión Interna garantiza que en el resultado de la consulta solamente se presenten los
elementos que cumplen con la condición de unión. Al incluir este nuevo elemento en la sintaxis
de la consulta SQL quedará:
SELECT {* |
{[{tabla|vista|alias}.]{nombre_columna} [as nombre_presentar1]
[,[{tabla|vista|alias}.]{nombre_columna} [as nombre_presentar2]] [. . . ] }}
FROM {tabla | vista} [alias] [, {tabla | vista} [alias]] [. . . ]
[NATURAL JOIN {tabla | vista} [alias]] [. . . ]
[{LEFT | RIGHT | FULL | INNER} JOIN {tabla | vista} [alias]
ON condición] [. . . ]
[WHERE condición]
4.3 STRUCTURED QUERY LANGUAGE (SQL) - DATA MANIPULATION LANGUAGE
(DML) 97
En el siguiente ejemplo se presenta una unión interna entre las tablas Clientes, Compras y
Productos condicionadas por la igualdad entre identificadores de las tablas:
En todas las uniones que necesitan una condición (derecha, izquierda, completa e interna),
la condición puede incluir comparaciones entre dos columnas, usar operadores lógicos, anidar
condiciones e incluir todas las columnas de las tablas previamente mencionadas en la cláusula
FROM de la consulta.
Funciones de grupo
La Agrupación permite formar grupos entre los datos obtenidos en la consulta para luego
realizar cálculos matemáticos con algunas columnas por cada uno de los grupos formados, entre
los posibles cálculos a realizar están: Suma, Promedio, Conteo, Máximo y Mínimo. En SQL la
función es soportada por la cláusula GROUP BY, cuando se utiliza esta cláusula la sintaxis de la
consulta es:
SELECT
{ [{tabla|vista|alias}.]{nombre_columna} [as alias_columna] |
{AVG | SUM | COUNT | MAX | MIN} ([{tabla|vista|alias}.]{nombre_columna})
[as alias_columna] }
[,[{tabla|vista|alias}.]{nombre_columna} [as alias_columna] |
{AVG | SUM | COUNT | MAX | MIN} ([{tabla|vista|alias}.]{nombre_columna})
[as alias_columna] ] [. . . ]
FROM {tabla | vista} [alias] [, {tabla | vista} [alias]] [. . . ]
[NATURAL JOIN {tablaN | vista} [alias]] [. . . ]
[{LEFT | RIGHT | FULL | INNER} JOIN {tabla | vista} [alias]
ON condición] [. . . ]
[WHERE condición]
GROUP BY [{tabla|vista|alias}.]{nombre_columna}
[, [{tabla|vista|alias}.]{nombre_columna}] [. . . ]
En la anterior sintaxis debe notarse que las funciones matemáticas disponibles para operar
las columnas son:
- AVG, que obtiene el promedio matemático de a columna para las tuplas que pertenecen a cada
uno de los grupos
98 CAPITULO IV - MODELO FÍSICO
- SUM, que realiza una suma de los valores de la columna para las tuplas de cada uno de los
grupos
- COUNT, realiza un conteo de las tuplas de cada uno de los grupos
- MAX, retorna el máximo valor de la columna para cada uno de los grupos
- MIN, retorna el mínimo valor de la columna para cada uno de los grupos
En caso que alguno de los valores de la columna operada por las anteriores funciones sea
NULL, este no se tomará en cuenta para la operación.
Cuando se utiliza la cláusula GROUP BY en una consulta SQL en la sección SELECT sólo
pueden incluirse dos tipos de elementos: las columnas que generan los grupos (que corresponden
a las columnas indicadas en la sección GROUP BY) y las funciones matemáticas previamente
descritas.
El siguiente ejemplo obtiene el total de productos comprados por cada cliente sumando las
cantidades registradas en la tabla compras por cada uno de ellos:
1. Realiza las operaciones de la cláusula FROM y aplica las restricciones de la cláusula WHERE
(Si ésta se encuentra definida), luego de este primer paso se tendría algo como lo siguiente:
3. Se realizan las operaciones por cada grupo de la consulta, para el grupo de “Fabian Ruano”
la suma de los valores de la columna cantidad es igual a siete (7) y para el grupo de “Maritza
Mera” es igual a nueve (9).
4. Finalmente se retornan los valores de cada columna para cada grupo y los de las colum-
nas calculadas:
4.3 STRUCTURED QUERY LANGUAGE (SQL) - DATA MANIPULATION LANGUAGE
(DML) 99
El siguiente ejemplo SQL presenta un listado con cantidad de compras realizadas, promedio
de productos por compra y máximo de productos por compra y mínimo de productos por compra
para cada cliente. La consulta incluye a todos los clientes incluso si no han realizado compras,
en tal caso presenta las operaciones como cero (0).
Orden en la Consulta
Hasta ahora el Orden de presentación de los resultados en la ejecución de una consulta
SQL depende del orden que se hayan almacenado en la base de datos o cualquier orden que el
intérprete SQL que se esté utilizando le desee dar. La sentenciaORDER BY permite ordenar
descendente o ascendentemente teniendo en cuenta una o más columnas de las tablas o vistas
involucradas en la consulta. La sintaxis con este nuevo elemento queda así:
SELECT {*|
{ [{tabla|vista|alias}.]{nombre_columna} [as alias_columna] |
{AVG | SUM | COUNT | MAX | MIN} ([{tabla|vista|alias}.]{nombre_columna})
[as alias_columna] }
[,[{tabla|vista|alias}.]{nombre_columna} [as alias_columna] |
{AVG | SUM | COUNT | MAX | MIN} ([{tabla|vista|alias}.]{nombre_columna})
[as alias_columna] ] [. . . ] }
FROM {tabla | vista} [alias] [, {tabla | vista} [alias]] [. . . ]
[NATURAL JOIN {tabla | vista} [alias]] [. . . ]
[{LEFT | RIGHT | FULL | INNER} JOIN {tabla | vista} [alias]
ON condición] [. . . ]
[WHERE condición]
[GROUP BY [{tabla|vista|alias}.]{nombre_columna}
[, [{tabla|vista|alias}.]{nombre_columna}] [. . . ] ]
[ORDER BY [{tabla|vista|alias}.]{nombre_columna} [DESC]
100 CAPITULO IV - MODELO FÍSICO
[, [{tabla|vista|alias}.]{nombre_columna} [DESC]] [. . . ] ]
Para ordenar los registros de la consulta por nombre de cliente y cantidad de productos
comprados se deberá modificar para que quede:
El resultado será:
Debe notarse que luego de ordenar los registros por el nombre del cliente de forma ascendente
se ordenaron por cantidad comprada de forma descendente. Si no se especifica el ordenamiento
descendente con el constructo DESC por defecto se realiza ordenamiento ascendente.
4.3.2 Sub-Consultas
Como seguramente ya se habrá notado en la sección anterior, el resultado de una consulta
siempre será una tabla, pues bien, dichos resultados pueden ser incluidos en la sección FROM
de consultas de orden superior para ser usadas como fuentes de datos. En palabras simples: se
pueden realizar consultas sobre resultados de otras consultas.
En esta sección se llamará consulta de orden superior a toda consulta que incluya una o más
4.3 STRUCTURED QUERY LANGUAGE (SQL) - DATA MANIPULATION LANGUAGE
(DML) 101
sub-consultas. La sintaxis de las consultas de orden superior queda así:
SELECT {*|
{ [{tabla|vista|alias}.]{nombre_columna} [as alias_columna] |
{AVG | SUM | COUNT | MAX | MIN} ([{tabla|vista|alias}.]{nombre_columna}) [as alias_columna]
}
[,[{tabla|vista|alias}.]{nombre_columna} [as alias_columna] |
{AVG | SUM | COUNT | MAX | MIN} ([{tabla|vista|alias}.]{nombre_columna})
[as alias_columna] ] [. . . ] }
FROM {tabla | vista | (sub-consulta)} [alias] [, {tabla | vista} [alias]] [. . . ]
[NATURAL JOIN {tabla | vista | (sub-consulta)} [alias]] [. . . ]
[{LEFT | RIGHT | FULL | INNER} JOIN {tabla | vista | (sub-consulta)}
[alias] ON condición] [. . . ]
[WHERE condición]
[GROUP BY [{tabla|vista|alias}.]{nombre_columna}
[, [{tabla|vista|alias}.]{nombre_columna}] [. . . ] ]
[ORDER BY [{tabla|vista|alias}.]{nombre_columna} [DESC]
[, [{tabla|vista|alias}.]{nombre_columna} [DESC]] [. . . ] ]
El siguiente ejemplo hace uso de sub consultas para obtener el listado total de compras realizado
por los clientes con código menor que 702.
La sub-consulta renombrada como Alfa obtiene el listado de clientes con que cumplan la
condición, dentro de ella además se renombran las columnas:
102 CAPITULO IV - MODELO FÍSICO
Existen operadores especiales que permiten hacer comparaciones entre una columna y un
listado de valores, los operadores usados para ello son:
- ALL: retorna verdadero cuando se cumple que la comparación entre el valor de la columna y
cada uno de los elementos de la lista es verdadera.
- ANY: retorna verdadero cuando se cumple que la comparación entre el valor de la columna y al
menos uno de los elementos de la lista es verdadera.
- IN: retorna verdadero cuando el valor de la columna específica está en el listado.
El siguiente es un ejemplo de uso del operador IN, obtienen de la lista de empleados sola-
mente aquellas tuplas cuyo código este en el listado {701, 703}.
SELECT *
FROM Clientes
WHERE Clientes.Codigo IN (701, 703)
El resultado es:
A continuación se utiliza el operador ANY para obtener la información de los productos que
tengan precio mayor que alguno de los precios del siguiente listado: {750, 1200}
SELECT *
FROM Productos
WHERE Precio > ANY (750, 1200)
4.3 STRUCTURED QUERY LANGUAGE (SQL) - DATA MANIPULATION LANGUAGE
(DML) 103
El resultado es:
Para obtener los productos que tengan precio mayor que todos los elementos del listado:
{750,1200} bastará con modificar la consulta reemplazando ANY por ALL.
SELECT *
FROM Productos
WHERE Precio > ALL (750, 1200)
El resultado es:
Los listados para comparación pueden ser provistos por resultados de sub-consultas que
retornen una sola columna. Por ejemplo, el siguiente SQL retorna el listado de precios para los
productos que haya comprado el cliente con código 701 haciendo uso de sub-consultas para la
condición:
SELECT *
FROM PRODUCTO
WHERE Identificador IN (
SELECT IdenficadorProducto
FROM Compras
WHERE CodigoCliente = 701)
4.3.3 Inserción
La cláusula INSERT del LMD permite realizar la inserción de nuevos registros en las tablas,
previamente creadas, de la base de datos. El formato general de la sentencia es:
104 CAPITULO IV - MODELO FÍSICO
Luego de la ejecución de dicha sentencia nuestra tabla Personal quedará con los siguientes
valores:
Nótese que el campo Nombres se obvió de la instrucción, esto se puede hacer porque dicho
campo permite valores NULL (no es obligatorio), en ese orden de ideas la siguiente sentencia es
INCORRECTA:
INSERT INTO Personal (Apellidos, Nombres) VALUES (‘Gómez’, ‘María’)
En este caso el intérprete SQL asume que los valores deben insertarse teniendo en cuenta
el orden en que fueron suministrados en la sentencia y el orden en que fueron creados los campos
a la hora de definir la tabla, por tanto, luego de ejecutar la anterior consulta la tabla tendría la
siguiente información.
4.3 STRUCTURED QUERY LANGUAGE (SQL) - DATA MANIPULATION LANGUAGE
(DML) 105
Esto es: el primer valor enviado se intentará asignar a la primera columna de la tabla, el
segundo valor a la segunda columna y así sucesivamente. Entonces, si se decide usar esta sintaxis
para la sentencia INSERT se debe tener en cuenta el orden de la creación de los atributos de la
tabla.
Qué pasaría con las sentencias INSERT que no incluyen especificación de campos si. . . .
1. Luego de creada la tabla decido eliminar una de las columnas?
2. Luego de la operación anterior inserto una columna nueva?
En la cláusula INSERT también se deben tener en cuenta los tipos de datos de las columnas
“destino”. Usualmente los tipos de datos numéricos (integer, float, decimal, etc.), se insertan
directamente en la sentencia y en caso del carácter de separación decimal se utiliza el punto (.)
debido a que la coma (,) hace parte de la sintaxis de la cláusula.
De otro lado los valores para los tipos no-numéricos (char, varchar, datetime, etc.) requie-
ren estar delimitados por comillas simples (‘) cuando se incluyen en una sentencia INSERT.
4.3.4 Borrado
Para el borrado de una o más tuplas almacenadas en las tablas de la base de datos en SQL
existe el constructo DELETE con el siguiente formato general:
DELETE FROM <nombre tabla> [WHERE <condición>]
La sentencia:
DELETE FROM Factura
Haciendo uso de condicionales con listas es posible eliminar elementos con un listado cons-
tante como el siguiente: {7200, 9600}
Es posible utilizar sub-consultas para seleccionar los elementos a borrar, por ejemplo en el
siguiente SQL se eliminan todos los registros cuyo IVA sea mayor al IVA de todos las compras
vendidos por “Sandra Roa”
DELETE FROM Factura
WHERE IVA > ALL (
SELECT IVA
FROM Factura
WHERE Vendedor = ‘Sandra Roa’)
4.3.5 Actualización
SQL provee constructos para la actualización de datos existentes en una tabla de la base de
datos, la sintaxis de la sentencia es:
UPDATE {Tabla}
SET {NombreColumna} = {NuevoValor} [,{NombreTabla} = {NuevoValor}] [. . . ]
[WHERE {condicion}]
La sentencia establece los nuevos valores a las columnas de todas las tuplas que cumplan
con la condición, si la condición se omite se asume que se van a actualizar todas las tuplas de la
tabla.
El NuevoValor puede ser una constante o el resultado de operaciones entre diferentes tipos
de datos (operaciones matemáticas, operaciones de cadenas, etc).
Para los siguientes ejemplos se utilizara la tabla Factura con los siguientes datos y columnas:
108 CAPITULO IV - MODELO FÍSICO
En el siguiente ejemplo se establece a la columna IVA el valor del 1500 y como vendedor
“Fabian Ruano” para todas las tuplas de la tabla:
UPDATE Factura
SET IVA = 1500 , Vendedor = ‘Fabian Ruano’
UPDATE Factura
SET Total = (Total * 1.1)
UPDATE Factura
SET Vendedor = ‘Fabian Ruano’
WHERE IVA > 7500 AND Numero IN (401,402)
UPDATE Factura
SET FechaCompra = ‘2013/11/01’
WHERE Numero IN (
SELECT Numero
FROM Factura
WHERE Vendedor = ‘Maria Vidal’
)
organización.
Sistema operativo: además del hardware, es necesario que el software sobre el que se soportan
los sistemas gestores de base de datos sea seguro. Los sistemas operativos proveen varios mé-
todos de acceso a su información: interfaz gráfica, escritorio remoto, puertos, servicios, entre
otros. Se debe garantizar que dicho software restrinja el acceso de la información solamente a las
personas o aplicaciones autorizadas. Usualmente es responsabilidad del departamento de soporte
técnico de las organizaciones velar porque los sistemas operativos utilizados y la configuración
de los mismos garanticen la seguridad necesaria.
Humano: uno de los niveles que usualmente se descuida es el relacionado con el manejo de
información de seguridad por parte de los empleados de las organizaciones. Es necesario que
todos los empleados con acceso a los sistemas de bases de datos sean conscientes de las buenas
prácticas de seguridad, por ejemplo: creación de contraseñas seguras, modificación periódica de
las mismas, gestión de software anti-virus y anti-espías, entre otras. Este nivel suele ser frágil
porque depende de todos los usuarios del sistema de base de datos, que pueden llegar a ser
muchos o todos los empleados de la organización, deben generarse planes de concientización del
problema y de las buenas prácticas.
Sistema Gestor de Base de Datos: además de la línea de defensa que debe proveer el sistema
operativo, el SGBD debe garantizar que solamente los usuarios y/o roles autorizados accedan y
modifiquen las diferentes tablas, vistas e información que ellas contengan. Cualquier acceso a
la base de datos debe ser luego de una autenticación contra el SGBD. El funcionamiento de la
seguridad a este nivel es responsabilidad del SGBD, sin embargo, para que este último actúe
correctamente el administrador debe encargarse de configurar las restricciones y permisos de
acceso. Dado que este documento se enfoca en el diseño y gestión de bases de datos principal-
mente desde el punto de vista del Sistema Gestor de Bases de Datos, el contenido de esta sección
se enfocará en el último nivel de seguridad, es decir, en el relacionado con el SGBD. Los SGBD
proveen varios constructos para gestionar y controlar el acceso a las bases de datos con el ánimo
de garantizar que las acciones sobre los objetos de la base de datos (metadatos y datos), sólo sean
realizados por aquellos usuarios que tienen los permisos para hacerlo. Este sistema de seguridad
se basa en permitir o negar acciones sobre los elementos de la base de datos a roles o usuarios.
4.4.2 Usuarios
Un usuario se compone básicamente de Nombre y Contraseña. Para crear un usuario en una base
de datos se utiliza el siguiente código SQL:
CREATE USER <nombre_usuario> IDENTIFIED BY <contraseña>
Es necesario que quien ejecute los comandos previos posea permisos de administrador sobre la
base de datos o en su defecto tenga los privilegios para gestión de usuarios.
4.4 USUARIOS, ROLES Y PRIVILEGIOS 111
4.4.3 Roles
Un Rol (papel), es una abstracción que, entre otras cosas, facilita la gestión de privilegios y
restricciones sobre los objetos de una base de datos. Al igual que a los usuarios, a los roles se
les definen permisos y restricciones. A un usuario se le pueden asignar uno o más roles, y un
rol puede ser asignado a uno o muchos usuarios. Cuando un usuario tiene asignado un rol tiene
los mismos privilegios y restricciones del rol.Para definir un nuevo rol se utiliza el siguiente
comando:
CREATE ROLE <nombre_rol>
Dado que el rol solamente tiene un nombre, no hay acciones de modificación sobre estos,
existe solamente la acción de borrado que tiene la siguiente sintaxis:
DROP ROLE <nombre_rol>.
4.4.4 Privilegios
En esta sección se describirán los privilegios que se pueden conceder a roles o a usuarios
y los constructos SQL necesarios para asignarlos. Es de resaltar que estos privilegios pueden
establecerse a tablas, vistas o a partes de ambas.
Selección (SELECT): proporciona los permisos de consulta sobre los objetos relacionados.
Inserción (INSERT): permite insertar nuevos registros en los objetos relacionados al privilegio.
Actualización (UPDATE): permite modificar la información contenida en los objetos relaciona-
dos.
Borrado (DELETE): permite eliminar registros o tuplas contenidas en los objetos relacionados.
Referencia (REFERENCES): permite crear “constraints” que referencia a la tabla relacionada
al privilegio.
Alteración (ALTER): permite realizar modificaciones a la tabla relacionada.
Indexación (INDEX): permite crear índices en la tabla relacionada.
Cabe anotar que la anterior lista de privilegios es la soportada por ORACLE, el listado de posibles
privilegios puede variar dependiendo del SGBD.
De otro lado, para remover los privilegios previamente asignados a usuarios o roles se puede
utilizar la siguiente sintaxis:
REVOKE <privilegio> ON <objeto_bd> FROM {<nombre_usuario> | <nombre_rol>}
Existe un privilegio especial que le permite conceder dichos privilegios a otros roles o usuarios,
para ello es necesario adicionar la sentencia “WITH GRANT OPTION” al final del SQL utilizado
para otorgar privilegios. Para remover este privilegio especial es necesario agregar la cláusula
“CASCADE” al final del comando para revocar privilegios.
Existe además un constructo que permite establecer todos los privilegios posibles mediante una
sola sentencia, este es “ALL PRIVILEGES”.
112 CAPITULO IV - MODELO FÍSICO
Incluyendo las tres últimas cláusulas, la sintaxis para asignación de privilegios queda de la
siguiente forma:
GRANT {ALL PRIVILEGES | <privilegio> } ON <objeto_bd> TO {<nombre_usuario> |
<nombre_rol>} [WITH GRANT OPTION]
Para que se puedan ejecutar una acción de conceder uno o más privilegios sobre un objeto
de la base de datos, quien está ejecutando el procedimiento debe tener, además de los privilegios
a otorgar, los permisos para otorgarlos a otros usuarios o roles.
Crear el código SQL necesario para realizar las siguientes acciones orientadas a mejorar la
seguridad de la base de datos:
usuarios
Solución al ejercicio
i.
CREATE USER eruano IDENTIFIED BY abcd1234
CREATE USER smroa IDENTIFIED BY mnln4567
CREATE USER mgaona IDENTIFIED BY wxyz9876
ii.
CREATE ROLE Administrador
CREATE ROLE Cliente
iii.
GRANT Administrador TO eruano
iv.
GRANT Cliente TO smroa
GRANT Cliente TO mgaona
v.
GRANT ALL PRIVILEGES ON Persona TO Administrador
GRANT ALL PRIVILEGES ON Transaccion TO Administrador
GRANT ALL PRIVILEGES ON Item Transaccion TO Administrador
GRANT ALL PRIVILEGES ON Producto TO Administrador
vi.
REVOKE ALL PRIVILEGES ON Persona TO Cliente
REVOKE ALL PRIVILEGES ON Transaccion TO Cliente
REVOKE ALL PRIVILEGES ON Item Transaccion TO Cliente
REVOKE ALL PRIVILEGES ON Producto TO Cliente
GRANT Select ON Persona TO Cliente
GRANT Select ON Producto TO Cliente
vii.
GRANT Insert, Update ON ItemTransaccion TO mgaona WITH GRANT OPTION
5 — APÉNDICE A. Ejemplo de diseño e imple-
mentación de una base de datos relacinal en
POSGRESQL
Se desea crear una base de datos para una organización dedicada a la gestión de recursos
forestales, la cual desea gestionar todo el proceso de registro del plan de manejo forestal realizado
para el aprovechamiento de especies forestales por personas naturales o jurídicas. Para tal fin se
cuenta con la siguiente información:
Con respecto al conjunto de especies forestales o individuos vegetales que controla la orga-
nización, cabe resaltar que están organizadas por clases, estas tienen un código, nombre de
clasificación, valor en pesos y descripción. Una clase de recurso forestal tiene de una a muchas
especies forestales. Las especies forestales tienen un código de especie, nombre común y cientí-
fico, familia, género y descripción del conjunto de características de la especie. Un especie solo
deberá pertenecer a una clasificación.
La organización exige para poder realizar el registro de un plan de manejo forestal primero se
deba llevar a cabo una solicitud de aprovechamiento forestal y que esta esté aprobada. Dicha
solicitud contiene el código de la solicitud, fecha de registro, área forestal total que se desea
aprovechar, edad y tamaño del bosque, finalidad, tiempo de duración del aprovechamiento,
numero del predio, estado de la solicitud (aprobada, derogada) y el empleado que la atendió. De
los predios se debe gestionar el número catastral, nombre, área y municipio donde está ubicado.
Una solicitud deberá incluir solo a un predio y un predio podrá estar incluido en una a muchas
solicitudes de aprovechamiento. Con respecto a los interesados en realizar las solicitudes de
aprovechamientos, es preciso dejar claro que pueden ser de dos tipos, personas naturales o
personas jurídicas. Si es una persona natural se identificará con su número de RUT, nombre,
apellidos, teléfono. Si es una persona jurídica se identificará con su número de NIT del negocio,
nombre, dirección y municipio donde está ubicado, además de la información de su representante
legal, es decir su número de RUT, nombre, apellidos, teléfono. Un interesado realiza de una a
muchas solicitudes de aprovechamiento y estas deben pertenecer solo a un interesado.
De los empleados que realizan el trámite de la solicitud se debe gestionar su número de RUT,
nombre, apellidos, teléfono, grupo sanguíneo, sexo (Hombre o Mujer). Es importante tener
presente que no todos los empleados atienden los tramites, pero una solicitud debe ser tramitada
por un empleado.
Las solicitudes de aprovechamiento podrán generar de uno a muchos planes de manejo forestal,
de estos se debe controlar el código, número de registro, fecha de ingreso, funcionario que
efectúa el trámite del registro, profesional que realizó el plan de manejo forestal, observaciones.
Los planes de aprovechamiento contienen de una a muchas especies forestales, de estas se debe
estipular la cantidad.
Con respecto al profesional, es preciso especificar que se refiere a un ingeniero forestal, este es el
encargado de realizar un plan de manejo forestal a un interesado en realizar un aprovechamiento
forestal. Del forestal se debe gestionar número de RUT, tarjeta profesional, nombre, apellidos,
teléfono.
APÉNDICE A. Ejemplo de diseño e implementación de una base de datos
116 relacinal en POSGRESQL
Figura 5.1: A.1. Diagrama E/R para la base de datos del Plan de Manejo Forestal
Creación de Tablas:
END;
LANGUAGE ‘plpgsql’;
En el modelo se especificaron algunos atributos con asterisco (*) al final del nombre, esto
indica que dichos atributos tienen un dominio especifico, a continuación se presenta esa lista de
dominios:
En el modelo E-R se incluye una relación Tercero que agrupa tanto los proveedores como
los compradores. Se realiza esta simplificación porque para ambos (proveedores y compradores),
se requiere almacenar la misma información.
APÉNDICE B. Ejemplo de diseño e implementación de una base de datos
126 relacional en ORACLE
6.3 B.3. DISEÑO LÓGICO
/*==============================================================*/
/* Table: APARTAMENTO */
/*==============================================================*/
create table APARTAMENTO (
INMCODIGO CHAR(20) not null,
NUMERO_PISO INTEGER,
NUMERO_APTO INTEGER,
6.4 B.4. IMPLEMENTACION ORACLE 127
/*==============================================================*/
/* Table: ASIGNACION */
/*==============================================================*/
create table ASIGNACION (
PROCODIGO CHAR(20) not null,
EMPCODIGO INTEGER not null,
CARGO VARCHAR2(50) not null,
TAREAS CLOB not null,
DURACION VARCHAR2(30) not null,
constraint PK_ASIGNACION primary key (PROCODIGO, EMPCODIGO)
);
/*==============================================================*/
/* Table: BODEGA */
/*==============================================================*/
create table BODEGA (
INMCODIGO CHAR(20) not null,
CAPACIDAD_VOLUMEN FLOAT not null,
constraint PK_BODEGA primary key (INMCODIGO)
);
/*==============================================================*/
/* Table: CASA */
/*==============================================================*/
create table CASA (
INMCODIGO CHAR(20) not null,
CANTIDAD_PISOS INTEGER not null,
constraint PK_CASA primary key (INMCODIGO)
);
/*==============================================================*/
/* Table: COMPRA */
/*==============================================================*/
create table COMPRA (
TERCODIGO CHAR(20) not null,
PROCODIGO CHAR(20) not null,
CODIGO_SUM CHAR(20) not null,
FECHA_SOLICITUD DATE not null,
CANTIDAD INTEGER not null,
VALOR_UNITARIO NUMBER(8,2) not null,
FECHA_ENTREGA DATE not null,
constraint PK_COMPRA primary key (TERCODIGO, PROCODIGO, CODIGO_SUM, FE-
CHA_SOLICITUD)
);
APÉNDICE B. Ejemplo de diseño e implementación de una base de datos
128 relacional en ORACLE
/*==============================================================*/
/* Table: CONTIENE */
/*==============================================================*/
create table CONTIENE (
ESPTIPO INTEGER not null
constraint CKC_ESPTIPO_CONTIENE check (ESPTIPO in (0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,2
INMCODIGO CHAR(20) not null,
CANTIDAD INTEGER not null,
AREA_TOTAL_ FLOAT not null,
constraint PK_CONTIENE primary key (ESPTIPO, INMCODIGO)
);
/*==============================================================*/
/* Table: CUOTAS_CREDITO */
/*==============================================================*/
create table CUOTAS_CREDITO (
TRANUMERO INTEGER not null,
CUOCODIGO INTEGER not null,
NUMERO INTEGER not null,
ESTADO VARCHAR(20) not null
constraint CKC_ESTADO_CUOTAS_C check (ESTADO in (‘Planeacion’,‘Ejecucion’,‘Cierre’,‘Finalizado’)),
VALOR_MINIMO NUMBER(8,2) not null,
VALOR_PAGADO NUMBER(8,2) not null,
FECHA_LIMITE DATE not null,
constraint PK_CUOTAS_CREDITO primary key (TRANUMERO, CUOCODIGO)
);
/*==============================================================*/
/* Table: EMPLEADO */
/*==============================================================*/
create table EMPLEADO (
EMPCODIGO INTEGER not null,
IDENTIFICACION_NUMERO INTEGER not null,
IDENTIFICACION_TIPO VARCHAR(20) not null
constraint CKC_IDENTIFICACION_TI_EMPLEADO check (IDENTIFICACION_TIPO in
(‘Cedula Ciudadania’,‘Cedula Extrangeria’)),
NOMBRES VARCHAR2(100) not null,
APELLIDOS VARCHAR2(100) not null,
FECHA_NACIMIENTO DATE not null,
LUGAR_NACIMIENTO VARCHAR2(100) not null,
GENERO VARCHAR(20) not null
constraint CKC_GENERO_EMPLEADO check (GENERO in (‘Masculino’,‘Femenino’)),
TELEFONOS CLOB,
CORREO_ELECTRONICO VARCHAR2(100),
CARGO VARCHAR2(50) not null,
SALARIO_MES NUMBER(8,2) not null,
CUENTA_BANCO VARCHAR2(50),
CUENTA_TIPO INTEGER,
CUENTA_NUMERO VARCHAR2(20),
6.4 B.4. IMPLEMENTACION ORACLE 129
/*==============================================================*/
/* Table: ESPACIO */
/*==============================================================*/
create table ESPACIO (
ESPTIPO INTEGER not null
constraint CKC_ESPTIPO_ESPACIO check (ESPTIPO in (0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22)
NOMBRE VARCHAR2(256),
constraint PK_ESPACIO primary key (ESPTIPO)
);
/*==============================================================*/
/* Table: EXPERIENCIA_LABORAL */
/*==============================================================*/
create table EXPERIENCIA_LABORAL (
EMPCODIGO INTEGER not null,
EXPCODIGO CHAR(10) not null,
FECHA_INICIO DATE not null,
FECHA_FINALIZACION DATE,
ENTIDAD_O_EMPRESA VARCHAR2(100) not null,
CARGO VARCHAR2(50) not null,
TIPO_CONTRATO VARCHAR(20) not null
constraint CKC_TIPO_CONTRATO_EXPERIEN check (TIPO_CONTRATO in (‘Fijo Me-
dio Tiempo’,‘Fijo Tiempo Completo’,‘Indefinido Medio Tiempo’,‘Indefinido Tiempo Comple-
to’,‘Prestacion Servicios’,‘Otro’)),
constraint PK_EXPERIENCIA_LABORAL primary key (EMPCODIGO, EXPCODIGO)
);
/*==============================================================*/
/* Table: FORMACION */
/*==============================================================*/
create table FORMACION (
EMPCODIGO INTEGER not null,
FORMCODIGO VARCHAR2(10) not null,
TITULO VARCHAR2(100) not null,
INSTITUCION_O_ENTIDAD VARCHAR2(100) not null,
DURACION VARCHAR2(30) not null,
constraint PK_FORMACION primary key (EMPCODIGO, FORMCODIGO)
);
/*==============================================================*/
/* Table: GRUPO_SOLUCIONES */
/*==============================================================*/
create table GRUPO_SOLUCIONES (
INMCODIGO CHAR(20) not null,
TIPO VARCHAR(20) not null
constraint CKC_TIPO_GRUPO_SO check (TIPO in (‘Alquiler’,‘Venta’)),
APÉNDICE B. Ejemplo de diseño e implementación de una base de datos
130 relacional en ORACLE
NOMBRE VARCHAR2(256) not null,
VALOR_ADMON_MES NUMBER(8,2),
constraint PK_GRUPO_SOLUCIONES primary key (INMCODIGO)
);
/*==============================================================*/
/* Table: INCLUYE */
/*==============================================================*/
create table INCLUYE (
TRANUMERO INTEGER not null,
INMCODIGO CHAR(20) not null,
constraint PK_INCLUYE primary key (TRANUMERO, INMCODIGO)
);
/*==============================================================*/
/* Table: INMUEBLE */
/*==============================================================*/
create table INMUEBLE (
INMCODIGO CHAR(20) not null,
PROCODIGO CHAR(20),
UBICACION_DIRECCION VARCHAR(50) not null,
UBICACION_BARRIO VARCHAR(50) not null,
UBICACION_CIUDAD VARCHAR(50) not null,
constraint PK_INMUEBLE primary key (INMCODIGO)
);
/*==============================================================*/
/* Table: LOCAL_COMERCIAL */
/*==============================================================*/
create table LOCAL_COMERCIAL (
INMCODIGO CHAR(20) not null,
USOS_SUGERIDOS CLOB not null,
constraint PK_LOCAL_COMERCIAL primary key (INMCODIGO)
);
/*==============================================================*/
/* Table: PAGO_MENSUAL */
/*==============================================================*/
create table PAGO_MENSUAL (
TRANUMERO INTEGER not null,
PAGCODIGO INTEGER not null,
FECHA DATE not null,
MES_PAGADO VARCHAR2(6) not null,
constraint PK_PAGO_MENSUAL primary key (TRANUMERO, PAGCODIGO)
);
6.4 B.4. IMPLEMENTACION ORACLE 131
/*==============================================================*/
/* Table: PROVEE */
/*==============================================================*/
create table PROVEE (
SUMCODIGO CHAR(20) not null,
TERCODIGO CHAR(20) not null,
COSTO_VENTA NUMBER(8,2) not null,
constraint PK_PROVEE primary key (SUMCODIGO, TERCODIGO)
);
/*==============================================================*/
/* Table: PROYECTO_CONSTRUCCION */
/*==============================================================*/
create table PROYECTO_CONSTRUCCION (
PROCODIGO CHAR(20) not null,
EMPCODIGO INTEGER not null,
NOMBRE VARCHAR2(256) not null,
FECHA_INICIO DATE not null,
FECHA_FINALIZACION DATE not null,
ESTADO VARCHAR(20) not null
constraint CKC_ESTADO_PROYECTO check (ESTADO in (‘Planeacion’,‘Ejecucion’,‘Cierre’,‘Finalizado’)),
constraint PK_PROYECTO_CONSTRUCCION primary key (PROCODIGO)
);
/*==============================================================*/
/* Table: REPRESENTANTE_LEGAL */
/*==============================================================*/
create table REPRESENTANTE_LEGAL (
REPCODIGO CHAR(20) not null,
NOMBRES VARCHAR2(100) not null,
IDENTIFICACION INTEGER not null,
TIPO_IDENTIFICACION VARCHAR(20) not null
constraint CKC_TIPO_IDENTIFICACI_REPRESEN check (TIPO_IDENTIFICACION in (‘Ce-
dula Ciudadania’,‘Cedula Extrangeria’)),
TELEFONOS_ CLOB,
CORREO_ELECTRONICO VARCHAR2(100),
constraint PK_REPRESENTANTE_LEGAL primary key (REPCODIGO)
);
/*==============================================================*/
/* Table: SOLUCION */
/*==============================================================*/
create table SOLUCION (
INMCODIGO CHAR(20) not null,
AREA_CONSTRUIDA FLOAT not null,
AREA_TOTAL_ FLOAT not null,
COSTO_ALQUILER NUMBER(8,2),
COSTO_VENTA NUMBER(8,2) not null,
PORCENTAJE_CREDITO FLOAT,
APÉNDICE B. Ejemplo de diseño e implementación de una base de datos
132 relacional en ORACLE
INMCODIGOGRUPO CHAR(20),
CODIGO_UBICACION VARCHAR(20),
constraint PK_SOLUCION primary key (INMCODIGO)
);
/*==============================================================*/
/* Table: SUMINISTRO */
/*==============================================================*/
create table SUMINISTRO (
SUMCODIGO CHAR(20) not null,
NOMBRE VARCHAR2(256) not null,
UNIDAD_MEDIDA CHAR(10) not null,
constraint PK_SUMINISTRO primary key (SUMCODIGO)
);
/*==============================================================*/
/* Table: TERCERO */
/*==============================================================*/
create table TERCERO (
TERCODIGO CHAR(20) not null,
REPCODIGO CHAR(20),
TIPO_PERSONA VARCHAR(20) not null
constraint CKC_TIPO_PERSONA_TERCERO check (TIPO_PERSONA in (‘Natural’,‘Juridica’)),
NOMBRE VARCHAR2(256) not null,
TIPO_IDENTIFICACION_ VARCHAR(20) not null
constraint CKC_TIPO_IDENTIFICACI_TERCERO check (TIPO_IDENTIFICACION_ in (‘Ce-
dula Ciudadania’,‘Cedula Extrangeria’)),
NUMERO_IDENTIFICACION_ INTEGER not null,
TELEFONOS CLOB,
CORREO_ELECTRONICO VARCHAR2(100),
UBICACION_DIRECCION VARCHAR2(50),
UBICACION_BARRIO VARCHAR2(50),
UBICACION_CIUDAD VARCHAR2(50),
constraint PK_TERCERO primary key (TERCODIGO)
);
/*==============================================================*/
/* Table: TRANSACCION */
/*==============================================================*/
create table TRANSACCION (
TRANUMERO INTEGER not null,
TERCODIGO CHAR(20) not null,
EMPCODIGO INTEGER not null,
TIPO VARCHAR(20) not null
constraint CKC_TIPO_TRANSACC check (TIPO in (‘Alquiler’,‘Venta’)),
FECHA DATE not null,
VALOR NUMBER(8,2) not null,
constraint PK_TRANSACCION primary key (TRANUMERO)
);
6.4 B.4. IMPLEMENTACION ORACLE 133
6.4.2 Código SQL para manejar restricciones propias del problema modelado
Restricción de herencia disjunta entre las relaciones casa, apartamento, bodega y
local comercial
Es necesario garantizar que una misma solución no está registrada en más de un tipo, es
decir, garantizar que si se encuentra registrada como Casa no esté en ninguno de los otros tipos
(Apto, Bodega o Local), y así con todos los tipos de solución considerados.Para ello presentamos
dos posibles vías para garantizar lo requerido:
Solución 1: Establecer un check en cada una de las relaciones “hijo” que valide que el Có-
digo Inmueble no exista en ninguna otra de las relaciones “hijo”.
Solución 2: Crear un trigger para cada una de las relaciones “hijo” que se dispare al mo-
mento de insertar tuplas y que lance una excepción en caso de que el “Código Inmueble” exista
previamente en las otras relaciones “hijo”.
la problemática:
Solución 1: Establecer un check en cada una de las relaciones “hijo” que valide que el Có-
digo Inmueble no exista en ninguna otra de las relaciones “hijo”.
Solución 2: Crear un trigger para cada una de las relaciones “hijo” que se dispare al mo-
mento de insertar tuplas y que lance una excepción en caso de que el “Código Inmueble” exista
previamente en las otras relaciones “hijo”.
CREATE OR REPLACE TRIGGER tg_AddSol BEFORE INSERT ON Solucion FOR EACH
ROW
DECLARE
MiException EXCEPTION;
iContador INTEGER;
BEGIN
SELECT Count(*) INTO iContador FROM Grupo_Soluciones
WHERE Grupo_Soluciones.InmCodigo = :New.InmCodigo ;
If iContador > 0 THEN RAISE MiException; END IF
END;
CREATE OR REPLACE TRIGGER tg_AddGrpSol BEFORE INSERT ON Grupo_Soluciones
FOR EACH ROW
DECLARE
MiException EXCEPTION;
iContador INTEGER;
BEGIN
SELECT Count(*) INTO iContador FROM Solucion
WHERE Solucion.InmCodigo = :New.InmCodigo ;
If iContador > 0 THEN RAISE MiException; END IF
If iContador > 0 THEN RAISE MiException; END IF
END;
*******************************************************************
CREATE
TABLE ACTIVIDAD_ECONOMICA
(
ACT_Codigo INTEGER NOT NULL ,
ACT_Nombre VARCHAR2 (50) ,
ACT_Descripcion VARCHAR2 (50) ,
SEC_Codigo INTEGER
);
ALTER TABLE ACTIVIDAD_ECONOMICA ADD CONSTRAINT ACTIVIDAD_ECONOMICA_PK
PRIMARY
KEY
(
ACT_Codigo
)
;
*******************************************************************
CREATE
TABLE AGREMIACION
(
AGR_Numero_Juridico INTEGER NOT NULL ,
AGR_Nombre VARCHAR2 (50) ,
AGR_Año_Creacion DATE ,
AGR_Direccion VARCHAR2 (50) ,
ACT_Codigo INTEGER
);
ALTER TABLE AGREMIACION ADD CONSTRAINT AGREMIACION_PK PRIMARY KEY
(
AGR_Numero_Juridico
)
;
*******************************************************************
CREATE
TABLE CERTIFICADO
(
CER_Codigo INTEGER NOT NULL ,
CER_Fecha_Expedicion DATE ,
CER_Fecha_Vencimiento DATE
);
ALTER TABLE CERTIFICADO ADD CONSTRAINT CERTIFICADO_PK PRIMARY KEY
(
CER_Codigo
)
;
APENDICE C. Ejemplo de diseño e implementación de una base de datos
142 relacional
*******************************************************************
CREATE
TABLE CIUDAD
(
CIU_Codigo INTEGER NOT NULL ,
CIU_Nombre VARCHAR2 (50) ,
PAI_Codigo INTEGER NOT NULL
);
*******************************************************************
ALTER TABLE CIUDAD ADD CONSTRAINT CIUDAD_PK PRIMARY KEY
(
CIU_Codigo, PAI_Codigo
)
;
*******************************************************************
CREATE
TABLE EMPRESA
(
EMP_NIT VARCHAR2 (20) NOT NULL ,
EMP_Razon_Social VARCHAR2 (50) ,
EMP_Direccion VARCHAR2 (50) ,
EMP_Telefono CHAR (10) ,
CER_Codigo INTEGER ,
AGR_Numero_Juridico INTEGER
);
*******************************************************************
ALTER TABLE EMPRESA ADD CONSTRAINT EMPRESA_PK PRIMARY KEY
(
EMP_NIT
)
;
*******************************************************************
CREATE
TABLE PAIS
(
PAI_Codigo INTEGER NOT NULL ,
PAI_Nombre VARCHAR2 (50) ,
PAI_Poblacion VARCHAR2 (50) ,
PAI_Extension VARCHAR2 (50) ,
PAI_Region VARCHAR2 (50)
);
*******************************************************************
ALTER TABLE PAIS ADD CONSTRAINT PAIS_PK PRIMARY KEY
(
PAI_Codigo
)
;
7.4 C.4. IMPLEMENTACION 143
*******************************************************************
CREATE
TABLE PRODUCTO
(
PRO_Codigo INTEGER NOT NULL ,
PRO_Nombre VARCHAR2 (50) ,
PRO_Valor_Unitario NUMBER ,
EMP_NIT VARCHAR2 (20)
);
*******************************************************************
ALTER TABLE PRODUCTO ADD CONSTRAINT PRODUCTO_PK PRIMARY KEY
(
PRO_Codigo
)
;
*******************************************************************
CREATE
TABLE Registro_mercantil
(
COM_Codigo UNKNOWN
– ERROR: Datatype UNKNOWN is not allowed
NOT NULL ,
COM_Fecha DATE ,
COM_Cantidad INTEGER ,
COM_Valor NUMBER ,
EMP_NIT VARCHAR2 (20) ,
EMP_NIT1 VARCHAR2 (20) ,
PRO_Codigo INTEGER
);
*******************************************************************
ALTER TABLE Registro_mercantil ADD CONSTRAINT Registro_mercantil_PK PRIMARY
KEY
(
COM_Codigo
)
;
*******************************************************************
CREATE
TABLE SECTOR_ECONOMICO
(
SEC_Codigo INTEGER NOT NULL ,
SEC_Nombre VARCHAR2 (50) ,
SEC_Descripcion VARCHAR2 (50) ,
PAI_Codigo INTEGER
);
*******************************************************************
ALTER TABLE SECTOR_ECONOMICO ADD CONSTRAINT SECTOR_ECONOMICO_PK
PRIMARY KEY
(
APENDICE C. Ejemplo de diseño e implementación de una base de datos
144 relacional
SEC_Codigo
)
;
*******************************************************************
*******************************************************************
ALTER TABLE EMPRESA ADD CONSTRAINT EMPRESA_CERTIFICADO_FK FOREIGN
KEY
(
CER_Codigo
)
REFERENCES CERTIFICADO
(
CER_Codigo
)
;
*******************************************************************
ALTER TABLE PRODUCTO ADD CONSTRAINT PRODUCTO_EMPRESA_FK FOREIGN
KEY
(
EMP_NIT
)
REFERENCES EMPRESA
(
EMP_NIT
)
;
*******************************************************************
ALTER TABLE Registro_mercantil ADD CONSTRAINT Registro_mercantil_EMPRESA_FK
FOREIGN KEY
(
EMP_NIT
)
REFERENCES EMPRESA
(
EMP_NIT
)
;
*******************************************************************
Los textos de este libro se distribuyen bajo una Licencia Reconocimiento-CompartirIgual 3.0 Un-
ported (CC BY-SA 3.0) http://creativecommons.org/licenses/by-sa/3.0/deed.es_
ES