12 reglas de Codd

Las 12 reglas de Codd son un sistema de reglas propuestas por Edgar F. Codd, del
modelo relacional para las bases de datos, diseado para definir qu requiere un sistema
de administracin de base de datos.1
Codd se percat de que existan bases de datos en el mercado las cuales decan ser
relacionales, pero lo nico que hacan era guardar la informacin en las tablas, sin estar
estas tablas literalmente normalizadas; entonces ste public 12 reglas que un verdadero
sistema relacional debera tener aunque en la prctica algunas de ellas son difciles de
realizar. Un sistema podr considerarse "ms relacional" cuanto ms siga estas reglas.

[editar] Reglas

Regla 0: el sistema debe ser relacional, base de datos y administrador de sistema.

Ese sistema debe utilizar sus facilidades relacionales (exclusivamente) para
manejar la base de datos.

Regla 1: la regla de la informacin, toda la informacin en la base de datos es

representada unidireccionalmente, por valores en posiciones de las columnas
dentro de filas de tablas. Toda la informacin en una base de datos relacional se
representa explcitamente en el nivel lgico exactamente de una manera: con
valores en tablas.

Regla 2: la regla del acceso garantizado, todos los datos deben ser accesibles sin
ambigedad. Esta regla es esencialmente una nueva exposicin del requisito
fundamental para las llaves primarias. Dice que cada valor escalar individual en
la base de datos debe ser lgicamente direccionable especificando el nombre de
la tabla, la columna que lo contiene y la llave primaria.

Regla 3: tratamiento sistemtico de valores nulos, el sistema de gestin de base

de datos debe permitir que haya campos nulos. Debe tener una representacin de
la "informacin que falta y de la informacin inaplicable" que es sistemtica,
distinto de todos los valores regulares.

Regla 4: catlogo dinmico en lnea basado en el modelo relacional, el sistema

debe soportar un catlogo en lnea, el catlogo relacional debe ser accesible a los
usuarios autorizados. Es decir, los usuarios deben poder tener acceso a la
estructura de la base de datos (catlogo).

Regla 5: la regla comprensiva del sublenguaje de los datos, el sistema debe

soportar por lo menos un lenguaje relacional que;
1. Tenga una sintaxis lineal.
2. Puede ser utilizado recprocamente y dentro de programas de uso.

3. Soporte operaciones de definicin de datos, operaciones de manipulacin

de datos (actualizacin as como la recuperacin), seguridad e integridad
y operaciones de administracin de transacciones.

Regla 6: regla de actualizacin, todas las vistas que son tericamente

actualizables deben ser actualizables por el sistema.

Regla 7: alto nivel de insercin, actualizacin, y cancelacin, el sistema debe

soportar suministrar datos en el mismo tiempo que se inserte, actualiza o est
borrando. Esto significa que los datos se pueden recuperar de una base de datos
relacional en los sistemas construidos de datos de filas mltiples y/o de tablas
mltiples.

Regla 8: independencia fsica de los datos, los programas de aplicacin y

actividades del terminal permanecen inalterados a nivel lgico cuandoquiera que
se realicen cambios en las representaciones de almacenamiento o mtodos de
acceso.

Regla 9: independencia lgica de los datos, los cambios al nivel lgico (tablas,
columnas, filas, etc.) no deben requerir un cambio a una solicitud basada en la
estructura. La independencia de datos lgica es ms difcil de lograr que la
independencia fsica de datos.

Regla 10: independencia de la integridad, las limitaciones de la integridad se

deben especificar por separado de los programas de la aplicacin y se almacenan
en la base de datos. Debe ser posible cambiar esas limitaciones sin afectar
innecesariamente las aplicaciones existentes.

Regla 11: independencia de la distribucin, la distribucin de las porciones de la

base de datos a las varias localizaciones debe ser invisible a los usuarios de la
base de datos. Los usos existentes deben continuar funcionando con xito:
1. cuando una versin distribuida del SGBD se introdujo por primera vez
2. cuando se distribuyen los datos existentes se redistribuyen en todo el
sistema.

Regla 12: la regla del de la no subversin, si el sistema proporciona una interfaz

de bajo nivel (de registro a la vez) y luego de que esa interfaz no se pueda
utilizar para subvertir el sistema, por ejemplo: sin pasar por seguridad relacional
o limitacin de integridad.

Normalizacin de bases de datos

Para otros usos de este trmino, vase Normalizacin (desambiguacin).
El proceso de normalizacin de bases de datos consiste en aplicar una serie de reglas a
las relaciones obtenidas tras el paso del modelo entidad-relacin al modelo relacional.

Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.

Evitar problemas de actualizacin de los datos en las tablas.

Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relacin, aunque para que una
tabla sea considerada como una relacin tiene que cumplir con algunas restricciones:

Cada tabla debe tener su nombre nico.

No puede haber dos filas iguales. No se permiten los duplicados.

Todos los datos en una columna deben ser del mismo tipo.

Principales caractersticas del modelo de datos relacional.

Los objetivos de este modelo son:

Independencia fsica: el modo en el que se almacenan los datos no

influyen en su manipulacin lgica.

Independencia lgica: la modificacin de cualquier elemento de la

base de datos no debe influir en los programas y/o usuarios que
accede a subconjuntos parciales de los mismos.

Flexibilidad: de forma que ofrezca a cada usuario los datos de la

forma mas adecuada a la correspondiente aplicacin

Uniformidad: Las estructuras lgicas de los datos presentan un

aspecto uniforma tablas, lo que facialita la concepcin y
manipulacin.

Sencillez: El modelo debe resultar fcil de comprender y utilizar por

parte del usuario.

Estructuralmente, el elemento bsico del modelo relacional es la relacin y se representa

en forma de tabla. Las tablas estn formadas por:

Atributos: Conjunto de columnas que representan las propiedades de

las tablas.

Tuplas: Conjunto de filas que contienes los valores de cada uno de los
atributos para cada elemento de la relacin.

El dominio serian el conjunto de calores homogneos y atmicos

caracterizado por un nombre donde los atributos pueden tomar sus
valores. Los dominios pueden definirse por intencin o por extensin.

Dominio compuesto combinacin de dominios simples a la que se

pueden aplicar ciertas restricciones de integridad por ejemplo.
Existen tambin atributos compuestos

Grado: Nmero de atributos.

Cardinalidad : nmero de tuplas.

La definicin formal de relacin definida sobre n dominios, no

necesariamente distintos, es un subconjunto del producto cartesiano
de esos dominios, donde cada elemento de la relacin tupla es una
serie de valores ordenados. Las clases de relacin se pueden dividirse
en nominadas y sin nombre:
o

Las nominadas pueden ser:

Persistentes: Son las relaciones cuya definicin

permanece en la base de datos, borrndose solamente
por una accin explicita de un usuario. A su vez se
dividen en:

Relaciones de base: Existen por si mismas y no en

funcin de otras relaciones, Se crean
explcitamente su esquema de relacin y sin
extensiones y definicin

Vistas: Son relaciones derivadas que se definen

dando nombre a una expresin de consulta. Son
relaciones virtuales.

Instantneas. Son relaciones derivadas al igual

que las vistas pero con datos propios
almacenados, que son resultado de ejecutar la
consulta especificada o de guardar una relacin
base. No se actualizan cada bez que cambian los
datos pero se refrescan cada cierto tiempo.

Temporales: desaparecen de la base de datos en un

cierto tmelo sin una accin especifica del usuario.

Relaciones sin nombre: son los resultados de las consultas que

no se materializan sino que se entregan al usuario que ha
realizado la consulta, y pueden ser tanta resultados
intermedios como finales. Son siempre relaciones temporales

Adems de las tuplas, el modelo define claves:

Una clave candidata de una relacin es un conjunto de atributos que

identifican unvoca y minimamente cada tupla. En toda relacin
siempre hay al menos una clave candidata, pueden tener mas de una
las cuales se deben distinguir:

Clave primaria: Identifica a las tuplas de la relacin, la escoge

el usuario por consideraciones ajenas al modelo relacional

El resto de las claves candidatos que no se han elegido como

clave primaria se llaman Clave alternativas.

Clave ajena de una relacin R2 es un conjunto no vacio de

atributos cuyos valores han de coincidir con los valores de la
clave de candidata o primaria de una relacin R1. R1 y R2 no
son necesariamente distintas.

El modelo distingue dos tipos de restricciones: inherentes y semnticas.

Claves

Una clave primaria es aquella columna (o conjunto de columnas) que identifica

nicamente a una fila. La clave primaria es un identificador que va a ser siempre nico
para cada fila. Se acostumbra a poner la clave primaria como la primera columna de la
tabla pero es ms una conveniencia que una obligacin. Muchas veces la clave primaria
es numrica auto-incrementada, es decir, generada mediante una secuencia numrica
incrementada automticamente cada vez que se inserta una fila.
En una tabla puede que tengamos ms de una columna que puede ser clave primaria por
s misma. En ese caso se puede escoger una para ser la clave primaria y las dems
claves sern claves candidatas.
Una clave ajena (foreign key o clave fornea) es aquella columna que existiendo
como dependiente en una tabla, es a su vez clave primaria en otra tabla.
Una clave alternativa es aquella clave candidata que no ha sido seleccionada como
clave primaria, pero que tambin puede identificar de forma nica a una fila dentro de
una tabla. Ejemplo: Si en una tabla clientes definimos el nmero de documento
(id_cliente) como clave primaria, el nmero de seguro social de ese cliente podra ser
una clave alternativa. En este caso no se us como clave primaria porque es posible que
no se conozca ese dato en todos los clientes.
Una clave compuesta es una clave que est compuesta por ms de una columna.
La visualizacin de todas las posibles claves candidatas en una tabla ayudan a su
optimizacin. Por ejemplo, en una tabla PERSONA podemos identificar como claves su
DNI, o el conjunto de su nombre, apellidos, fecha de nacimiento y direccin. Podemos
usar cualquiera de las dos opciones o incluso todas a la vez como clave primaria, pero
es ms ptimo en la mayora de sistemas la eleccin del menor nmero de columnas
como clave primaria.

SELECT : La sentencia SELECT forma el ncleo de base de datos de SQL esta

sentencia sirve para seleccionar o recuperar la filas y columnas deseadas de las tablas de
nuestra base de datos. La sintaxis de la sentencia SELECT consta de 5 clusula
construida normalmente de la siguiente manera:
SELECT < LISTA DE CAMPOS>
FROM<LISTA DE TABLAS>
(WHERE < Especificacin de Seleccin de Filas>)
(GROUP BY <Especificacin de Agrupacin>)
(HAVING<Especificacin de seleccin de grupos>)
(ORDER BY <Especificacin de Ordenacin>).
WHERE: Para hacer una seleccin desde la misma tabla bajo ciertas condiciones o con
alguna restriccin, se debe usar la clusula WHERE, que corresponde al operador del
lgebra Relacional llamado Restriccin.
Los operadores de combinacin que pueden ser usados por el comando WHERE son los
lgicos y los propios de SQL:
OPERADORES LOGICOS:
= IGUAL
MAYOR
>= MAYOR IGUAL
< MENOR
<= MENOR IGUAL.
OPERADORES SQL:
Existen 4 operadores SQL con los cuales se puede operar cualquier tipo de datos de una
Base de Datos.
BETWEEN ... AND .... : Permite encontrar un conjunto de valores a partir de dos
valores dados incluyendo tambin estos mismos.
Ej. Sueldo Base y telfono (70000 y 300000)

SELECT NOMBRES, APELLIDOS, S_BASE, TELEFONO

FROM EMPLEADOS
WHERE S_BASE BETWEEN 70000 AND 300000;
IN : El operador IN chequea los valores en una lista especifica.
WHERE NOMBRE ATRIBUTO IN (11111-11112-11113)
Ejemplo:
SELECT NOMBRE, APELLIDOS, S_BASE, TELEFONO, FICHA
FROM EMPLEADOS
WHERE FICHA IN (11111-1112-11113);
** CUANDO QUIERA VER CARACTERES PONER APOSTROFE.
LIKE: El operador LIKE se usa cuando no se sabe exactamente el valor a buscar, a se
conoce solo una parte de l usando este operador es posible seleccionar filas parecidas
con un patrn de caracteres en el cual se reemplaza lo desconocido por un caracteres en
el cual se reemplaza lo desconocido por un carcter *, para reemplazar un solo carcter
ocupamos el comodn
*reemplaza todo
reemplaza un carcter
Mostrar todos los atributos de la tabla empleados cuyos apellidos comiencen con la letra
S. los apellidos que terminen con S
IS NULL: El operador concretamente busca los campos cuyos valores son nulos.
Ejemplo:
Buscar todos los empleados que no tienen valoren campo carga
WHERE NOMBRE atributo IS NULL
SELECT *
FROM EMPLEADOS
1 WHERE CARGAS IS NULL;

2 WHERE CARGAS IS NULL OR NOMBRES IS NULL;

OPERADORES NEGADOS:
NOT BETWEEN.... AND...
CARGAS ( 2 AND 4)
EJEMPLO
SELECT *
FROM EMPLEADOS
WHERE S_BASE NOT BETWWEN 100000 AND 800000;
NOT IN: Va ha mostrar todos lo que este fuera de la cadena
NOT LIKE: El patrn del campo no debe ser igual al patrn dado.
IS NOT NULL:
OPERADORES ARITMETICOS: Otros componentes de la clusula SELECT son las
expresiones aritmticas, una expresiones aritmticas es una combinacin de uno o ms
valores con operadores que le dan valor a un dato las expresiones aritmticas pueden
contener: Nombres de las columnas, valores constantes numricos y los operadores
aritmticos suma, resta, multiplicacin, divisin. Si una expresin aritmtica tiene ms
de un operador la primera prioridad la tiene los operadores, multiplicacin y divisin, si
se quiere alterar este orden se debe usar los parntesis.
SELECT NOMBRE, APELLIDOS sueldo *1,5.
SELECT NOMBRES, APELLIDOS, S_BASE * 1,5
FRON EMPLEADOS;
OPERADORES RELACIONALES: Los operadores relacionales con una o ms tablas
restriccin esta operacin selecciona y despliega datos de una tabla es posible desplegar
todas las filas o slo aquellas filas que cumplan con una condicin o varias condiciones
esto tambin es conocido como sub-conjunto horizontal.
RESTRICION: Pregunta cuales son los proveedores Santiaguinos
Respuesta: Ciudad = Santiago
PROYECCIN: Pregunta cuales son las ciudad en donde hay Proveedores

Respuesta: SELECT CIUDAD

FROM PROVEEDORES;
PRODUCTO:
Tabla elemento Tabla Proveedores
CODIGO 2 1 ATRIBUTO
Descripcin Color
Elemento Tarro pintura.
PRODUCTO es el resultado de cuando las filas de dos tablas son concatenadas, todas
las filas de la primera tabla son concatenada con las filas de la segunda tabla, esto
produce una nueva tabla.
Las tablas no necesitan tener la misma estructura (se van unir). Usualmente al hacer esta
operacin se produce un producto cartesiano sin una condicin de igualdad.
** cuando se crea la consulta hay que agregar en el SELECT el nombre de la tabla ms
el atributo.
Ejemplo:
SELECT ELEMENTOS.DESCRIPCION, COLORES.COLOR
FROM COLORES, ELEMENTO
Restriccin WHERE.COLORES.COLOR='AZUL';
EL JOIN: Es el resultado de cuando las filas que estn en dos tablas son conectadas de
acuerdo a una condicin doble.
Como trabaja: crear dos tablas
1 Pacientes
Cdigo nmero de 3
Nombre paciente
Cdigo de cama
2 Ubicacin

Cdigo de cama.
Descripcin
Seleccionar
Nombre de paciente y ubicacin. Y queda?
Ejemplo:
Conectar dos tablas de acuerdo a un atributo en comn:
SELECT PACIENTE.NOMBRE_PACIENTE, UBICACIN.Ubicacin
FRON PACIENTE, Ubicacin
WHERE UBICACIN Ubicacin.CODCAMA=PACIENTE.CODCAMA:
Otra etapa importante es la unin.
UNION: Despliega todas las filas que estn en una de las dos tablas. Para que dos tablas
puedan unir las estructuras de los datos seleccionados dichas estructuras de los datos
deben ser compatibles; es decir, si en ambas tablas hay tuplas iguales queda solo una de
ellas por lo tanto la duplicidad de elementos no se nota:
ORDER BY DIVISION
Crear dos tablas = Proveedores
Nombre texto
Ciudad Texto
Cdigo N entero o 0000
SELECT NOMBRE, CIUDAD, CODIGO
FROM PROVEEDORES
UNION
SELECT NOMBRE, CIUDAD, CODIGO
FROM PROVEEDORES, PROVEEDORES 2;

INTERSECCIN: Muestra todos los elementos que se repiten en las dos tablas.
Despliega todas las filas que estn en las dos tablas a la vez, tambin debe cumplir las
mismas condiciones que para la unin y queda:
SELECT PROVEEDORES
FROM PROVEEEDORES, PROVEEDORES
WHERE PROVEEDORES.CODIGO=PROVEEDORES2.CODIGO
DIFERENCIA: Es lo que est en la primera tabla que no se repite en la segunda.
SELECT PROVEEDORES
FROM PROVEEDORES
WHERE PROVEEDORES.CODIGO<>PROVEEDORES.CODIGO
O WHERE PROVEEDORES.CODIGO NOT=PROVEEDORES.CODIGO
FUNCIONES AGREGADAS
Las funciones agregadas son las que actan sobre los grupos de datos, m{as sobre filas
individuales. Los grupos de datos pueden ser una columna o un conjunto de columnas
incluyendo toda la tabla.
La funcin agregada es aplicada en la lnea del SELECT como si fuera un nombre de
columna la sintaxis general es:
SELECT FUNCION (NOMBRE COLUMA O *)
FROM
FUNCION AVG= Calcula el promedio de un conjunto de valores.
FUNCION COUNT= Cuenta el nmero de ocurrencia de los miembros de un conjunto.
FUNCION MAX= Determina el valor mximo de un conjunto de valores.
FUNCION MIN= Determina el valor mnimo de un conjunto de valores.
FUNCION SUM= Suma un conjunto de valores.
FUNCIONES DE GRUPO DE FILAS

Las clusulas DROPDRIVE sirve para ocupar los datos de acuerdo a un atributo en
comn AVG(S_BASE)
El SQL internamente hace la clasificacin de acuerdo al atributo incorporando en el
atributo DROPDRIVE
Una vez que los grupos estn formados, la funcin asociada al comando SELECT es
aplicada en forma individual a estos grupos, es decir, primero se ocupa DROPDRIVE.
Ejemplo:
Tabla empleado
SELECT CentroCosto, AVG(S_BASE)
FROM EMPLEADOS GROUP BY CentroCosto
HAVING= Al igual que la clusula WHERE para especificar la bsqueda por condicin
para grupos de filas se usa la clusula HAVING.
SELECT
FROM
(WHERE)
GROUP BY
HAVING= Acta sobre un grupo seleccionado.
Buscar todos los promedios -<< 150000.
SELECT CentroCosto, AVG(S_BASE) AS PROMEDIO.
FROM EMPLEADOS
GROUP BY CentroCosto
HAVING AVG(S_BASE) < 150000;
ORDER BY= La funcin ORDER BY permite ordenar los datos de acuerdo al valor de
un atributo asociado, este orden puede ser tanto ascendente como descendente.
ORDER BY NOMBRE CAMPO (ASC), CAMPO2 ASC
ORDER BY NOMBRE CAMPO (DESC), CAMPO2 DESC

Ejemplo:
SELECT CentroCosto, AVG(s_BASE)
FROM EMPLEADOS
GROUP BY CentroCosto
ORDER BY CentroCosto ASC; O
ORDER BY CentroCosto DESC;
SELECT CentroCosto, AVG(s_BASE), COUNT(FICHA)
FROM EMPLEADOS
WHERE TURNO <>NO
GROUP BY CentroCosto
ORDER BY CentroCosto DESC;
Consideraciones Generales
En un sistema de base de datos distribuida, los datos se almacenan en varios
computadores. Los computadores de un sistema distribuido se comunican entre s a
travs de diversos medios de comunicacin, tales como cables de alta velocidad o lneas
telefnicas. No comparten la memoria principal ni el reloj.
Los procesadores de un sistema distribuido pueden variar en cuanto su tamao y
funcin. Pueden incluir microcomputadores pequeos, estaciones de trabajo y sistemas
de computadores grandes de aplicacin general. Estos procesadores reciben diferentes
nombres, tales como localidades, nodos o computadores.
Un sistema distribuido de bases de datos consiste en un conjunto de localidades, cada
uno de las cuales puede participar en la ejecucin de transacciones que accedan a datos
de una o varias localidades. La diferencia principal entre los sistemas de base de datos
centralizados y distribuidos es que, en los primeros, los datos residen en una sola
localidad, mientras que, en los ltimos, se encuentran en varias localidades.
Relaciones "uno a uno"

Estas relaciones entre bases de datos se dan cuando cada campo clave aparece slo una
vez en cada una de las tablas.

Tomando un ejemplo del mundo real, una clara relacin de "uno a uno" podra ser, el
nombre de cualquier persona y su nmero de telfono. Si partimosdel supuesto en que
cada persona tiene un solo nmero de telfono, se podra hablar de una relacin "uno a
uno".
Grficamente, se podra representar de la siguiente manera:

Este tipo de relaciones se caracteriza poque cad uno de los campos define a aqul con el
que se relaciona. Es decir, conociendo el nombre de una persona podemos conocer su
nmero telefnico. O si sabemos su nmero telefnico, podemos identificar al dueo.
En estos cases, se suele aconsejar incluir todos los datos dentro de una sola tabla.
Relaciones de "uno a varios"

El ejemplo del caso anterior (cada persona, un telfono), si bien es correcto

tericamente, es muy improbable desde el punto de vista de la realidad. Conla gran
expansin de los telfonos, por lo general, cada persona tiene un nmero de telfono
fijo, y ademas del tefono mvil. Debemos tener en cuenta que de el de su casa tambin
tendr un nmero de telfono de empresa, y que quiz tambin sus mviles estn
divididos en ocio y trabajo.
Por ello, debemos tener nuestras bases de datos preparadas para ello. Este tipo de
relaciones es conocido como "uno a varios", y se podra representar de la siguiente
manera:

En este caso, lo aconsejable no es almacenar todos los datos en una sola tabla, sino lo
eficiente es hacerlo en tablas separadas, utilizando el identificador ID para relacionarlas.

Echemos un vistazo a la figura anterior. En la taba Nombre almacenamos el nombre y

apellido, con su ID o nmero identificador. En la otra tabla, Telfonos, almacenamos
nicamente nmeros de telfono, con su correspondiente nmero identificador, en este
caso TID. La manera en que se relaciona una con otra es mediante el identificador ID,
que est presente en ambas tablas.
A simple vista podemos advertir que la primera de las personas de la tabla nombres,
Juan Timan, tiene 2 nmeros telefnicos, pues su ID, que en este caso es 1, aparece en
dos de los telfonos de la otra tabla.
De este modo ser mucho mas sencillo cambiar, eliminar o ampliar los nmeros de
telfono en la misma tabla.

Si estas tablas estn creadas en MySQL, la sentencia que nos ayudara a encontrar todos
los telfonos de una determinada persona sera:
SELECT n.nombre, t.telf
FROM nombre n
INNER JOIN telefonos t ON n.id = t.id
WHERE n.nombre = "Juan Timan"
Relaciones de "varios con varios"

La ltima de la relaciones que podemos encontrar es la de "varios con varios". Dado que
en la vida las cosas rara vez son sencillas, ste ser el tipo de relacin que nos
encontraremos ms a menudo.
Volviendo al tema de los tefonos, hemos encontrado la manera de relacionar cada una
de las personas con sus diversos telfonos: el de su casa, el de su empresa, el mvil.
Pero no ser extrao tener en nuestra base de datos diversas personas que trabajen en la
misma empresa, por lo que el nmero de su trabajo ser el mismo, o miembros de una
misma familia, por lo que compartirn el mismo telfono de su hogar.
Cmo tratar este tipo de relaciones? Si nos limistamos a repetir dicho nmero de
tablas, estaremos creando problemas de redundancia de datos, que a largo plazo
lastrarn la rapidez y eficacia de nuestras tablas.
Este tipo de relaciones podra ilustrarse de la siguiente manera:

Como vemos, cada elemento de la bas de datos puede relacionarse libremente con uno o
varios miembros de las distintas tablas.
En estos casos no hay una regla fija a la que podamos acogernos, pero lo aconsejable es
aproximarse lo ms posible a la realidad, y no dudar en establecer tablas intermedias
que nos ayuden a asociar mejor los datos.

Volviendo al tema de los telfonos, imaginemos que varias personas de nuestra tabla
trabajan en la misma empresa ACME Productions tiene varias lneas, por lo que los
nmeros de telfono de trabajo de estas personas seran varios. Cmo representarlo en
nuestra base de datos?

En este caso hemos creado una tabla intermedia llamada "empresas". En la tabla
"nombres" incluimos un nuevo campo TID, que se relaciona con la tabla "empresas", y
es esta tabla la que se relaciona directamente con los telfonos. De esta manera,
podemos almacenar todos los datos con facilidad sin tener que repetir un slo nmero
telefnico.
Conclusin

Por muy complicadas que parezcan las relaciones en el mundo real, tengamos por
seguro que cuando queramos plasmarlas en nuestra base de datos corresponder alguna
de las tres opciones que hemos presentado. Por ello, no dudemos en invertir el tiempo
que sea necesario hasta encontrar la combinacin de bases de datos ptima que nos
permita modelar la realidad sin repetir ninguno de los datos.
El tiempo que invirtamos en este proceso lo recuperaremos con creces durante el
proceso de programacin, pues nos facilitar enormemente las cosas.

Restricciones inherentes.

No hay dos tuplas iguales, por lo que se deduce la obligatoriedad de

la clave.

La orden de las tuplas no es significativo

El orden de los atributos no es significativo.

Cada atributo slo puede tomar un nico valor del dominio sobre el
que est definido, no admitindose los grupos repetitivos. Entonces
se dice que la tabla que cumple esta condicin normalizada(1 forma
normal)

Regla de integridad de entidad: Ningn atributo que forme parte de la

clave primaria de una relacin puede tomar un valor nulo.

Restricciones semnticas.

Las principales son las siguientes:

Clave primaria: Permite declara a uin atributo p conjunto de atributos

como clave primaria de una relacin, por los que su calores no se
pueden repetir ni se nulos

Unicidad

Obligatoriedad

Integridad referencial

El modelo relacional, al igual que el resto de modelos, permite realizar las siguientes
funciones desde un punto de vista dinmico:

Insercin de tuplas.

Borrado de tuplas.

Modificacin de tuplas.

Consultas.

Fundamentos matemticos del modelo de datos relacional: Algebra

Relacional y Clculo Relacional.

El modelo relacional es el modelo lgico en el que se basan la mayora de los SGBD

comerciales en uso hoy en da. En primer lugar, se trata la descripcin de los principios
bsicos del modelo relacional: la estructura de datos relacional y las reglas de
integridad.
A continuacin, se presenta un tratamiento detallado del lgebra relacional, que es un
conjunto de operaciones para manipular la estructura de datos relacional y especificar
consultas de datos.
El lgebra relacional es un lenguaje procedural, mientras que el clculo relacional es un
lenguaje equivalente no procedural.

El modelo relacional se basa en dos ramas de las matemticas: la teora de conjuntos y

la lgica de predicados de primer orden. El hecho de que el modelo relacional est
basado en la teora de las matemticas es lo que lo hace tan seguro y robusto. Al mismo
tiempo, estas ramas de las matemticas proporcionan los elementos bsicos necesarios
para crear una base de datos relacional con una buena estructura, y proporcionan las
lneas que se utilizan para formular buenas metodologas de diseo.
Hay quien ofrece una cierta resistencia a estudiar complicados conceptos matemticos
para tan slo llevar a cabo una tarea bastante concreta. Es habitual escuchar quejas
sobre que las teoras matemticas en las que se basa el modelo relacional y sus
metodologas de diseo, no tienen relevancia en el mundo real o que no son prcticas.
No es cierto: las matemticas son bsicas en el modelo relacional. Pero, por fortuna, no
hay que aprender teora de conjuntos o lgica de predicados de primer orden para
utilizar el modelo relacional. Sera como decir que hay que saber todos los detalles de la
aerodinmica para poder conducir un automvil. Las teoras de la aerodinmica ayudan
a entender cmo un automvil puede ahorrar combustible, pero desde luego no son
necesarias para manejarlo.
La teora matemtica proporciona la base para el modelo relacional y, por lo tanto, hace
que el modelo sea predecible, fiable y seguro. La teora describe los elementos bsicos
que se utilizan para crear una base de datos relacional y proporciona las lneas a seguir
para construirla. El organizar estos elementos para conseguir el resultado deseado es lo
que se denomina diseo.