Clase3

•

• Clase 3
• MODELOS DE DATOS : Relacional
•

• Clase 3 - MODELOS DE DATOS: Relacional Atlantis University

En este capítulo, aprenderá a:
• En este capítulo, usted aprenderá:
• Cómo el modelo de base de datos relacional adopta una visualización lógica de los datos
• Describir los componentes básicos del modelo relacional son entidades, atributos y
relaciones entre entidades

• Cómo se organizan las entidades y cómo están relacionados a través de tablas
• Sobre operadores de bases de datos relacional, el diccionario de datos y el catálogo de
• sistema
• Cómo se maneja la redundancia de datos en el modelo de base de datos relacional
• Por qué es importante la indexación

En este capítulo aprenderá algunos detalles importantes sobre la estructura lógica
del modelo relacional.
Aprenderá que los componentes de datos básicos del modelo de base de datos relacional son

las entidades y los atributos, y verá cómo estos componentes de datos básicos encajan en una

estructura conocida como tabla. También, descubrirá que una razón importante de la simplicidad

del modelo base de datos relacional se debe a que sus tablas pueden ser tratadas como unidades

lógicas como unidades y no como unidades físicas. Asimismo, aprenderá cómo las tablas

independientes dentro de la base tos pueden estar relacionada entre sí. Después de aprender

sobre tablas, sus componentes y sus relaciones, conocerá los conceptos básicos conforman

el diseño de tablas. Ya que las tablas son una parte integral del diseño de bases de datos

relacionales, también aprenderá a reconocer las características de tablas bien y mal diseñadas.

Lcda. Carol Puche Modalidad - Online


3.1 Visión Lógica de los Datos
El modelo de datos relacional cambió permite al diseñador enfocarse en la representación lógica

de los datos y sus relaciones, en vez de sólo considerar los detalles del almacenamiento físico.

Si lo ponemos como un ejemplo de automóviles, la base de datos relacional utiliza transmisión

automática y nos libera de manipular la palanca de velocidades mientras oprimimos el pedal

del clutch (embrague). En pocas palabras, el modelo relacional nos permite visualizar los datos

lógicamente en vez de físicamente. El significado práctico de la visualización lógica está en
que nos recuerda el concepto sencillo de guardar en archivo. Aunque e¡ uso de una tabla nos

parece igual que utilizar un archivo, la ventaja de aquélla es que permite la independencias

de estructuras y de datos. Gracias a que podemos concebir la idea de almacenar registros

relacionados en tablas independientes, el modelo relacional es más fácil de entender que sus

predecesores jerárquicos y en red. A mayor simplicidad lógica aumenta la tendencia a obtener

metodologías de diseño de bases de datos más sencillas y eficaces.

Ya que la tabla tiene un papel prominente en el modelo relacional, merece una mirada más

cercana. Por tanto, iniciaremos nuestro estudio explorando los detalles de la estructura y del

contenido de la tabla.



3.1.1 Entidades y atributos
El diseño relacional empieza por definir las entidades que se requieren. Reeuerde que en

el capitulo 1 vimos que una entídad, es simplemente una persona, un LUGAR, un hecho u

objeto del que intentamos obtener información. Por ejemplo, en un ambiente universitario,

las entidades de interés serían los estudiantes, los profesores, los cursos entre otros. Si usted

trabaja en una línea aerea, las entidades serían los pilotos, los aviones, las rutas, los proveedores y

cualquier otro tipo de asunto de los que se pueda recolectar Información.

Las entidades se agrupan según sus características en común. Por ejemplo, se concentra a los

alumnos para formar un junto de entidades. Un conjunto de entidades es un grupo de éstas, las

cuales comparten ciertas características. Generalmente se prefiere que el nombre del conjunto

de entidades refleje cuál es su contenido, para que el diseñador sepa cual es la función de

dicho conjunto dentro de la base de datos. Si tomamos a los alumnos de cualquier universidad,

los encontraríamos en un conjunto de entidades llamado ESTUDIANTES. Enotras palabras, el

conjunto de entidades ESTUDIAN contiene muchas entidades estudiante. De la misma manera,

los profesores se almacenarían en un conjunto de entidades. llamado DOCENTES y los aviones de

una línea aérea entrarían en un conjunto bajo el nombre de FLOTA.

Las características de cada entidad reciben el nombre de atributos. Por ejemplo la entidad

ESTUDIANTES podría in los siguientes atributos: número de matrícula, nombre, promedio

de calificaciones, fecha de ingreso, fecha de nacimiento, domicilio, número telefónico, etc.

Igualmente, la aerolínea debe definir atributos para su entidad FLOTA: número de fecha de

su más reciente mantenimiento, horas de vuelo totales, horas de vuelo desde el más reciente

mantenimiento. Cada atributo deberá nombrarse adecuadamente a fin de recordar al usuario

cuál es su contenido. Digamos, si la entidad es ESTUDIANTES, el atributo “fecha de nacimiento”

debe guardarse como EST_NAC, o el atributo “número telefón quedaría como EST_NUM_TEL.

Así, con la entidad FLOTA, el atributo “número de avión” se almacenaría a FLOTA_NUM_AV y el

atributo “horas de vuelo” entraría como FLOTA_HR VUELO.



3.1.2 Tablas y sus Relaciones
La visualización lógica de la base de datos relacional se facilita al crear relaciones de datos

basadas

en una idea (lógica) conocida como tabla. Una tabla se percibe como una estructura

bidimensional compuesta de filas y columnas. En lo que se refiere al usuario de una tabla, una

tabla contiene un grupo de entidades relacionadas, es decir, un conjunto de entidades; por esa

razón, los términos conjunto de entidades y tabla a menudo se utilizan de manera indistinta. Por

otro lado, una tabla también se llama relación, debido a que el creador del modelo relacional

E.F.Codd, utilizó el término relación como sinónimo de tabla.

Características de una tabla relacional
1. Una tabla se percibe como una estructura bidimensional compuesta de filas y columnas.
2. Cada fila de la tabla (tupie) representa la ocurrencia de una sola entidad dentro del
conjunto de entidades.

3. Cada columna de la tabla representa un atributo, y cada columna tiene un nombre
distinto.

4. Cada intersección de fila/columna representa un valor de dato único.
5. Cada tabla debe tener un atributo o una combinación de atributos que identifique de
manera única a cada fila.

6. Todos los valores en una columna deben ajustarse al mismo formato de datos. Por
ejemplo, si al atributo se le asigna un formato de dato entero, todos los valores en la

columna que representen dicho atributo deben ser enteros.

7. Cada columna tiene un intervalo de valores específico conocido como dominio de
atributo.



La terminología de la base de datos relacional es muy precisa. Desafortunadamente, la

terminología del sistema de Archivos se coló al ambiente de las bases de datos, por lo tanto, en

ocasiones se hace referencia a las filas como registros, y a las columnas como campos. De vez en

cuando, se hace referencia a las tablas como archivos. Técnicamente hablando, la sustitución de

términos no siempre es apropiada; la tabla de base de datos es un concepto lógico más que físico

y los términos archivo, registro y campo, describen conceptos físicos. Sin embargo, mientras que

se reconozca que la tabla realmente es una idea lógica y no física, se puede pensar (a nivel
conceptual) en las filas de tabla como registros y en las columnas como campos. De hecho,

muchos vendedores de software de base de datos aún utilizan esta terminología de archivos.

Figura 3.1 Lista de Valores del Atributo en la Tabla Student



De la tabla STUDENT (ESTUDIANTE), mostrada en la figura 3.1, se pueden sacar las siguientes

conclusiones con a los puntos de la tabla 3.1.

1. La tabla STUDENT, mostrada en la figura 3.1 se percibe como una estructura bidimensional
compuesta de filas (tuplas) y doce columnas. También puede describirse como mencionando

que está compuesta de ocho registros y doce atributos (campos).

2. Cada fila en la tabla STUDENT describe una sola ocurrencia de entidad dentro del conjunto de
entidades junto de entidades está representado por la tabla STUDENT). Observe que la fila
(registro o entidad) dentro STU NUM = 321452 define las características (atributos o campos)

del estudiante William C. Browser. Por ejemplo la fila 4, en la figura 3.1, describe al estudiante

Walter H. Oblonski. Asimismo, la fila 3 describe a la Juliétte Brewer. Dado el contenido de la

tabla, el conjunto de entidades STUDENT incluye ocho entidades (filas).

3. Cada columna representa un atributo y cada una de ellas tiene un nombre distinto.
4. Cada intersección fila/columna contiene solamente un valor de dato. Los datos deben
clasificarse según su formato y su función. Aunque varios SGBD pueden soportar diferentes

tipos de datos, la mayoría soportan por lo menos los siguientes.

a. Numérico. Los datos numéricos son aquellos en los cuales se pueden realizar
procedimientos

aritméticos significantes, por ejemplo, STUJHRS y STU_GPA, en la figura 2.1, son atributos

numéricos. Por otra parte, STUJPHONE no es un atributo numérico, porque la adición y

sustracción de números telefónicos no da un resultado aritmético significante.

b. Carácter. Los datos carácter, también conocidos como datos de texto o datos cadena,
pueden contener cualquier carácter o símbolo no pensado para manipulación matemática.

En la figura 3.1, por ejemplo. STU_NAME, STU-FNAME, STUJNIT, STU_CLASS y STU_PHONE,
son atributos de

caracteres, de texto o de cadena.



c. Fecha. Estos atributos contienen fechas de calendario guardadas en un formato
especial conocido como formato de fecha Juliana. Aunque el almacenamiento físico de

la fecha Juliana es inmaterial para el usuario y para el diseñador, este formato de fecha

permite realizar una clase especial de aritmética conocida como aritmética de fecha Juliana.

Con ésta se puede determinar el número de días que han transcurrido entre el 5/12/1993 y

el 03/20/2002 simplemente restando 5/12/1993 de 03/29/2002. En la figura 3.1, STU_DOB,

puede clasificarse apropiadamente como atributo de fecha. La mayoría de los paquetes

de software de base de datos relacional soportan formatos de fecha (Juliana). Si bien, es

probable que el formato de fecha interno de la base de datos sea Juliana, están disponibles

muchos formatos diferentes de presentación

d. Lógico. Los datos lógicos pueden tener únicamente una condición de verdadero o
falso (sí o no), por ejemplo ¿un estudiante de tercer año viene de otra escuela? En la figura

3.1, el atributo

STU_TRANSFER utiliza el formato de datos lógico. Casi la mayoría de los paquetes de

software de

base de datos relacional soportan el formato de datos lógico. (Microsoft Access utiliza la

designación “Tipo de datos sí/no” para indicar un tipo de datos lógico.)

5. Cada tabla debe tener una clave primaria. En términos generales, la clave primaria es un
atributo que de una manera única identifica cualquier entidad dada (fila). En este caso, STC__

NUM es el número de estudiante), se seleccionó como clave primaria. Si se utilizan los datos

presentados en la figura 3.1, puede observar que el apellido de un estudiante (STU_LNAME) no

sería una buena clave primaria porque es probable encontrar varios estudiantes cuyo apellido

sea Smith. Incluso ni la combinación del apellido y el primer nombre (STU_FNAME) sería

apropiada como clave primaria, porque, como la figura 2.1 muestra, es muy encontrar más de un

estudiante llamado John Smith.



6. Todos los valores en una columna corresponden a las características del atributo de entidad.
Por ejemplo, una columna calificación promedio (STU_GPA) solamente contiene entradas STU_

GPA en cada una de las filas de xxxx

7. El intervalo de valores permisibles de la columna se conoce como su dominio. Como los
valores STU_GPAson limitados al intervalo 0-4, inclusive, el dominio es (0,4)

8. El orden de las filas y de las columnas es inmaterial para el usuario.

3.2 Claves
Una clave se compone de uno o más atributos que a su vez determinan a otros (por ejemplo, un

número de factura cuantifica todos los atributos de ésta, por ejemplo, la fecha, el nombre del

cliente, etcétera). Ya se presentó un tipo conocida como clave primaria. Dada la estructura de

la tabla STUDENT, mostrada en la figura 3.1, la definición selección de la clave primaria parece

bastante simple; sin embargo, como la clave primaria desempeña un rol muy en el ambiente

relacional, analizaremos con más cuidado sus propiedades. Además, existen otras clases de claves

bién merecen atención. En esta sección se presentarán las superclaves, las claves candidato y las

claves secundaria, El rol de la clave se basa en un concepto conocido como determinación. En el

contexto de una tabla de base - la expresión ‘’A determina a B” indica que si se conoce el valor del

atributo A se puede determinar el de B. Por si se conoce el STU_NUM en la tabla STUDENT (véase

la figura 3.1) se puede determinar el apellido de ese estudiante, su calificación promedio, su

número telefónico, etcétera. La notación taquigráfica para “A determina a B” es A—A determina a

B, C y D, entonces se escribe A --> B, C, D.



Por consiguiente, con los atributos de la tabla STUDENT en la figura 3.1, puede representarse la

expresión STU_NUMSTU_NAME” escribiendo: STU_NUM-> STU_LNAME

De hecho el valor STU_NUM en la tabla STUDENT, determina todos los valores de atributo del

estudiante. Por ejemplo, se puede escribir: STU_NUM-> STU_LNAME, STU_FNAME, STU_INIT

Por el contrario STU_NUMno está determinado por STU_NAME, porque es muy posible que varios

estudiantes se apelliden “Smith”. El principio de de determinación es muy importante, porque se

utiliza en la definición de un concepto de base de datos relacional conocido como dependencia

funcional. El término, dependencia funcional se puede definir más fácilmente de esta manera. El

atributo B es funcionalmente dependiente de A sí A determina a B.Más precisamente,

El atributo B es funcionalmente dependiente del atributo A si cada valor
en la columna A determina uno y sólo un valor en la columna B.
Si se utiliza el contenido de la tabla STUDENT en la figura 3.1, es apropiado decir que STU_NAME

es funcionalmente de STU_NUM. Por ejemplo, el valor 321452 de STU_NUM determina el

valor 2134 de STU_PHONE. Por otra parte, STU_NUM no es funcionalmente dependiente de

STU_PHONE, porque el valor 2267 de STU_PHONE está asociado con dos valores de STU_NUM:

324274 y 324291 (aparentemente, algunos estudiantes comparten un teléfono). Asi mismo, el

valor 324273 de STU_NUM determina el valor Smith de STU_LNAME, pero el valor de STU_NUM

es funcionalmente dependiente de STU_LNAME, porque más de un estudiante puede apellidarse

‘’Smith”. La definición de dependencia funcional puede ser generalizada para abarcar el caso en

el cual el valor del atributo determinante ocurre más de una vez en una tabla. La dependencia

funcional se puede definir entonces de la siguiente manera:
NOTA
El atributo A determina a B (es decir, B es funcionalmente dependiente de A) si todas las filas en la tabla,
que concuerdan con el valor del atributo A, también deben hacerlo
con el atributo B.’

Debemos tener cuidado al momento de definir la dirección de la dependencia, por ejemplo, la

GiganticState University determina la clasificación de sus estudiantes como se muestra en la tabla

3.2.


Tabla 3.2. Clasificación del estudiante

Horas completadas Clasificación

Menos que 30 Fr

30-59 So

60-89 Jr

90 o más Sr

Dado el contenido de la tabla 3.2, la clasificación del estudiante depende de las horas

completadas, por consiguiente puede escribir: STU_HRS --> STU_CLASS Pero el número

específico de horas no depende de la clasificación. Es muy posible encontrar un junior (estudiante

de tercer año) con 62 horas completadas o uno con 84. En otras palabras, la clasificación (STU_

CLASS) no determinará y solo un valor de horas completadas (STU_HRS). Tomemos en cuenta

que se podría usar más de un atributo para definir la dependencia funcional; es decir, una clave

puede componer de más de un atributo. Tal clave de atributo múltiple se conoce como clave

compuesta.



Cualquier atributo que forma parte de una clave se conoce como atributo de clave. Por ejemplo,

en la tabla STUDENT el apellido de un estudiante no sería suficiente para funcionar como clave.

Por otra parte, la combinación de apellido, primer nombre y teléfono de casa, es muy probable

que sí produzca correspondencias únicas de los atributos restantes. Por ejer se puede escribir:

STU_LNAME, STU_FNAME, STU_INIT, STU_PHONE -> STU_HRS, STU_CLASS

o

STU_LNAME. STU_FNAME, STU_INIT, STU_PHONE-> STU_HRS, STU_CLASS, STU_GPA

O

STU_LNAME, STU_FNAME, STUJNIT, STU_PHONE —› STU_HRS, STU_CLASS, STU_GPA STU_DOB

Debido a la posible existencia de una clave compuesta, se puede refinar aún más la noción de

dependencia funcional especificando la dependencia funcional completa.

Si el atributo (B) es funcionalmente dependiente de una clave compuesta (A), pero
no de cualquier subconjunto clave compuesta, el atributo (B) es por completo
funcionalmentedependiente de (A).

Dentro de la amplia clasificación de clave, se pueden definir varias claves especializadas, por

ejemplo, una superclave cualquier clave que identifica cada entidad de manera única. En

resumen, la superclave determina funcionalmente y los demás atributos de la entidad. Dada la

estructura de la tabla STUDENT, la superclave puede ser cualquiera siguientes:

STU_NUM

STU_NUM, STU_LNAME

STU NUM. STU_LNAME, STU_INIT



De hecho, STU_NUM con o sin atributos adicionales, puede ser una superclave, aunque los

atributos adicionales sean xxxx

La clave candidato se puede describir como una superclave sin redundancias. Si utilizamos esta

distinción, podemos determinar la clave compuesta:

STU_NUM, STU_LNAME

Es una superclave, pero no es una clave candidato porque STU_NAME por sí mismo es una clave

candidato! La combinación

STU_NAME,STU_FNAME, STU _INIT, STU_PHONE

También podría ser una clave candidato, siempre y cuando se deseche la posibilidad de que dos

estudiantes puedan tener el mismo apellido, primer nombre, inicial y número telefónico.

Si hubiera decidido incluir el número de seguro social del estudiante como uno de los atributos

en la tabla STUDENT de 3.1, tal vez de nombre STU_SOCSECNUM, tanto éste como STU_NUM

habrían sido claves candidato, porque cualquiera de ellas identificaría a cada estudiante de una

manera única.

En este caso, la selección de STU_NUM como clave primaria sería determinada por elección del

diseñador o por los requerimientos del usuario final. Observe, incidentemente que una clave

primaria es una superclave lo mismo que una clave candidato.

En una tabla, la clave primaria debe ser única de modo que identifique de manera única a cada

fila. Cuando se da este caso, la tabla exhibe integridad de identidad. Para mantener la integridad

de identidad no se permite un “valor” nulo es decir, ningún ingreso de datos en absoluto) en la

clave primaria.

NOTA
Un nulo NO significa un cero o un espacio. Al presionar la barra espaciadora del teclado se produce un
espacio en blanco. Se crea un nulo cuando oprime la tecla Enter del teclado sin haber hecho ningún tipo
de entrada previa.



Aunque siempre se pueden evitar los nulos en atributos diferentes de los encontrados en la clave

primaria, deben utilizarse parquedad. Si los nulos se utilizan inapropiadamente, pueden crear

problemas, porque pueden tener muchos significados diferentes. Por ejemplo, un nulo puede

representar:

• Un valor de atributo desconocido.
• Un valor de atributo conocido, pero faltante.
• Una condición “no aplicable”.
Dependiendo de la complejidad del software de desarrollo de aplicación, los nulos pueden

acarrear problemas cuando se utilizan funciones tales como COUNT, AVERAGE y SUM. Además,

los nulos pueden crear problemas lógicos cuando vinculan tablas relacionales. La redundancia

controlada hace que la base de datos relacional trabaje. Las tablas dentro de base de datos

comparten atributos que permiten vincularlas. Observe, por ejemplo, que las dos tablas

(PRODUCT_VENDOR ) en la figura 3.3, comparten el atributo común de nombre VEND_CODE.

Figura:3.3 Ejemplo de una Base de Datos Relacional Simple



Al examinar la tabla 3.3, se puede observar que el valor de VEND_CODE en una tabla pu-

ede utilizarse para señalar valor correspondiente en la otra tabla. Por ejemplo, el valor 235 de

VEND_CODE, en la tabla PRODUCT, señala al vendedor Henry Ortozo en la tabla VENDOR. Por

consiguiente, se ve que el producto “Houselite chain saw, 16 in. bar“ fue entregado por Henry

Ortozo, y que puede ser contactado llamando al 615-899-3425. Se puede hacer la misma concor-

dancia para el producto “Steel tape, 12-ft length” en el tabla PRODUCT

Recuerde que en la convención de nominación se utiliza el prefijo PROD en la figura 3.3 para

indicar que los atributos pertenecen” a la tabla PRODUCT. Por consiguiente, el prefijo VEND en

VEND_CODE, de la tabla PRODUCT indica que VEND_CODE señala a alguna otra tabla en la base

de datos. En este caso, el prefijo VEND se utiliza para se la tabla VENDOR en la base de datos.

Se puede describir el vínculo al observar que se crea cuando dos tablas comparten un atributo

con valores comunes específicamente, la clave primaria de una tabla aparece otra vez como

clave foránea en una tabla relaciona:- clave foránea es un atributo cuyos valores corresponden a

los de la clave primaria en la tabla relacionada. Por ejemplo en la tabla PRODUCT. Como la tabla

VENDOR no está vinculada a una tercera tabla, la tabla VENDOR no contiene clave foránea.

Figura:3.3: Esquema Relacional de la base de datos CH2_SALE_CO

La clave foránea contiene valores concordantes o nulos, la tabla(s) que utiliza(n) esa clave

foránea se dice que exhibe(n) integridad referencial. En otras palabras, integridad referencial

significa que si la clave foránea contiene un valor, éste se na fila (tuple) que ya existe en otra

relación. Observe que la integridad referencial se mantiene entre las tablas PRODUCT y VENDOR

que se muestran en la figura 3.3.



Por último una clave secundaria es aquella que se utiliza estrictamente para propósitos de

recuperación de datos. Supongamos que se guardan los datos de unos clientes en una tabla

CUSTOMER en la que el número de cliente es la clave primaria ¿Cree que la mayoría de los cli-

entes recordarán su número? La recuperación de los datos de un cliente se facilita y se utiliza el

apellido y el número telefónico de éste. En este caso, la clave primaria es el número del cliente y

la clave secundaria es la combinación del apellido y el número telefónico del cliente. Debemos

tomar en cuenta que una clave secundaria no necesariamente da un resultado único. Por ejem-
plo, el apellido y el número telefónico de un cliente podrían dar varias correspondencias, si varios

miembros de la familia Smith viven en una casa donde sólo hay una línea telefónica. Así mismo,

la combinación del apellido y del código postal podrían dar docenas de correspondencias, que

luego pueden filtrarse en busca de una correspondencia específica.

3.3 Reglas de Integridad Revisitadas
Se verá que las reglas de integridad de base de datos relacional son muy importantes para un

buen diseño de base. Muchos sistemas de administración de base de datos relacional hacen

cumplir automáticamente las relaciones de integridad. Sin embargo, es mejor asegurarse de que

el diseño de sus aplicaciones se ajusten a las reglas de integridad de entidades y a las referencia-

les que mencionamos al principio de este capítulo. Estas reglas se resumen en la tabla

TIPO DE INTEGRIDAD DESCRIPCIÓN

INTEGRIDAD DE ENTIDAD Todas las entradas de clave primaria son únicas, y ninguna parte de unac-
Requerimiento lave puede ser nula.
Garantiza que cada entidad tendrá una identidad única y asegura que los
Propósito valore_ clave ajena puedan referirse apropiadamente a valores de clave
primaria.
Ninguna factura puede tener un número duplicado, ni puede ser nulo. En
Ejemplo
suma las facturas están identificadas de manera única por sus números.



TIPO DE INTEGRIDAD DESCRIPCIÓN
Una clave ajena puede tener una entrada nula mientras que no forme
parte de primaria de su tabla o una entrada igual al valor de la clave
INTEGRIDAD DE ENTIDAD
primaria en una tabla con la cual está relacionada (todo valor de la clave
Requerimiento
ajena no nulo debe hacer referencia un valor de clave primaria
existente).
Hace posible que un atributo NO tenga un valor correspondiente, pero
será imposible que tenga una entrada válida. La aplicación de la regla de
Propósito
integridad referencial hace posible eliminar una fila en una tabla cuya
clave primaria contiene valores de claves ajenas, iguales en otra tabla.
A un cliente podría no (aún) tener un representante de ventas asignado
Ejemplo (número) pero será imposible que tenga un representante de ventas
inválido (número).


Clase3

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (20)

Similar a Clase3

Similar a Clase3 (20)

Más de Javier Juliac

Más de Javier Juliac (20)

Clase3