GRUPO DE TRABAJO:

SALINAS VARAS NELSON

TORRES AGURTO MICHELLE

CARRASCO TRIVIÑO JEAN

LOPEZ OROZCO MIGUEL

SEMINARIO DE PUNTO NET

ING. CEDEÑO

2012

UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS ADMINISTRATIVAS

ING. EN SISTEMAS ADMINISTRATIVOS COMPUTARIZADOS

MODELO RELACIONAL Es el modelo más utilizado en la actualidad para modelar problemas reales y

administrar datos dinámicamente

ÍNDICE DE TRABAJO

1.- MODELO RELACIONAL .......................................................................... 1

1.1.- BREVE HISTORIA ................................................................................ 1

1.2.- EVOLUCIÓN DEL MODELO RELACIONAL ................................................. 2

1.3.- OBJETIVOS DEL MODELO RELACIONAL .................................................. 4

1.4.- TABLAS ............................................................................................. 5

1.4.1.- TIPOS DE TABLAS ......................................................................... 6

1.5.- TERMINOLOGÍA DEL MODELO RELACIONAL ............................................ 8

1.5.1.- ESQUEMA ..................................................................................... 8

1.5.2.- INSTANCIAS ................................................................................. 8

1.5.3.- ATRIBUTOS .................................................................................. 9

1.5.4.- ESQUEMAS ................................................................................... 9

1.5.5.- TUPLAS ........................................................................................ 9

1.5.6.- DOMINIOS ................................................................................... 9

1.6.-CLAVES EN EL MODELO REALCIONAL ..................................................... 9

1.7.- VALORES NULL ................................................................................. 10

1.8.- RESTRICCIONES EN EL MODELO RELACIONAL ...................................... 11

1.8.1.- RESTRICCIONES INHERENTES ...................................................... 11

1.8.2.- RESTRICCIONES DE USUARIO ...................................................... 11

1.9.- LAS 12 REGLAS DE CODD .................................................................. 14

1.10.- TIPOS DE RELACIONES EN UN MODELO ENTIDAD-RELACION ................ 16

1.11.- EJEMPLO DE UN MODELO RELACIONAL MEDIANTE ESQUEMA Y

CODIFICACIÓN SQL SERVER 2005 .............................................................. 17

1.11.1.- CODIFICACIÓN EN SQL SERVER 2005 .......................................... 18

2.- CONCLUSIÓN ...................................................................................... 21

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 1

1.- MODELO RELACIONAL

1.1.- BREVE HISTORIA

El Dr. Edgar Frank Codd un brillante matemático y científico de la computación

nacido en Inglaterra que vivió la mayor parte de su vida en los Estados Unidos

trabajando y desarrollando sus ideas que culminaron en una serie de informes

técnicos acerca de una nueva manera de organizar y acceder los datos. A

partir de estos trabajos publicó en 1970 el artículo A Relational Model of Data

for Large Shared Data Banks, algo así como Un modelo de datos relacional

para grandes bancos de datos compartidos.

Planteó que los sistemas de bases de datos deberían presentarse a los usuarios

con una visión de los datos organizados en estructuras llamadas relaciones,

definidas como conjuntos de tuplas (filas) y no como series o secuencias de

objetos, con lo que el orden no es importante. Por tanto, detrás de una

relación puede haber cualquier estructura de datos compleja que permita una

respuesta rápida a una variedad de consultas. Codd hizo entonces “El modelo

relacional de bases de datos” haciendo énfasis en que el usuario de un

sistema relacional sólo debía preocuparse por el ¿qué consultar? y no el

¿cómo? de las estructuras de almacenamiento lo que ahora se conoce como

modelo físico.

Las actividades de los usuarios en sus terminales y la mayoría de programas

de aplicación no debería verse afectados cuando se cambia la representación

interna de los datos o incluso cuando se cambian algunos aspectos de la

representación externa. Se necesitará cambiar la representación de los datos a

menudo como resultado de los cambios en el tráfico de las consultas,

actualizaciones e informes y como consecuencia del crecimiento natural en los

tipos de información almacenada.”

Un grupo de la Universidad de Berkeley en California, liderado por Michael

Stonebreaker, creyó en la idea del modelo relacional y obtuvo financiamiento

para desarrollar un sistema, el Ingres, cuya primera versión se presentó en

1974 y fue el primer manejador relacional de bases de datos funcional. Esto

tuvo como consecuencia que IBM reaccionara poniendo en marcha otro

sistema relacional, el System R con características de multiusuario y un

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 2

lenguaje de consulta estructurado, el SEQUEL que luego pasaría a llamarse

SQL (Structured Query Language). Para entonces Larry Ellison, un empresario

del Valle del Silicón, había tomado ventajas de los escritos de Codd para crear

un nuevo producto y una nueva empresa que hasta la fecha se conoce como

Oracle.

El modelo relacional es un modelo de datos basado en la lógica de predicados y

en la teoría de conjuntos.

1.2.- EVOLUCIÓN DEL MODELO RELACIONAL

La aparición del modelo relacional representa un verdadero hito en el

desarrollo de las bases de datos, ya que ha marcado tres etapas diferentes,

conocidas como generaciones de los SGBD’s:

• Pre-relacionales. Los SGBD se basan en modelos Codasyl (en red) y

Jerárquico y ficheros planos (flat files).

• Relacionales. Los sistemas relacionales ganan madurez en el

mercado y los productos basados en este modelo van desplazando poco

a poco a los sistemas basados en punteros de la etapa pre-relacional.

• Post-relacionales. Aparecen manifiestos de otros modelos de datos,

en especial los orientados a objeto. Se distinguen manifiestos puristas

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 3

OO que dan lugar a SGBDs-OO puros como O2, Gemstone, etc. y, en

paralelo, corrientes evolutivas del modelo relacional que relajan

hipótesis básicas del modelo original de Codd (relajación de la primera

forma normal) para ofrecer estructuras de datos más complejas. Se

propone una evolución desde el modelo relacional a SGBDs-OO

relacionales, p. ej. SQL3.

Sobre el modelo relacional se han definido los estándares ANSI e ISO del

extendido lenguaje de definición y manipulación de bases de datos relacionales

SQL (Structured Query Language).

Tabla 1. Evolución del modelo en varias etapas

P

R

E

R

E

L

A

C

I

O

N

A

L

1968 - 1970 ↔ Surge el modelo

1970 . . . ↔ Desarrollos teóricos

1973 - 1978 ↔ Prototipos (Ingres,

sistema R, etc. . .)

R

E

L

A

C

I

O

N

A

L

1978 ↔ QBE

1979 ↔ Oracle

1980 ↔ Ingres

1981 ↔ SQL

1982 ↔ DB2

1986 ↔ SQL/ ANS

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 4

1987 ↔ SQL ISO (9075)

1989 ↔ SQL Adendum

1989 ↔ Manifiesto de los SGBO

1990 ↔ Modelo Relacional Versión 2

P

O

S

T

R

E

L

A

C

I

O

N

A

L

1990 ↔ Manifiesto de los SGBO- 3G

1992 ↔ SQL 92

1995 ↔ 3er Manifiesto

1999 ↔ SQL 3

1.3.- OBJETIVOS DEL MODELO RELACIONAL

El objetivo principal es llegar a un buen modelo relacional que represente el

diagrama entidad-relación ideado por el usuario y mejorado.

Independencia física: La forma de almacenar los datos, no debe influir en su

manipulación lógica.

Independencia lógica: Las aplicaciones que utilizan la base de datos no

deben ser modificadas por que se modifiquen elementos de la base de

datos.

Flexibilidad: La base de datos ofrece fácilmente distintas vistas en función

de los usuarios y aplicaciones.

Uniformidad: Las estructuras lógicas siempre tienen una única forma

conceptual (tablas).

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 5

Sencillez.

Destacar que todo el proceso en los diferentes pasos de ejecución del

diagrama a tratar, se presentan al usuario de forma interactiva a través de

interfaces gráficas de usuario; por ello, el usuario estará al tanto de las

limitaciones que puedan conllevar las decisiones que toma gracias a los

posibles itinerarios propuestos por la aplicación.

Se utilizan actualmente para modelar problemas reales y administrar datos

dinámicamente.

Recuperar o almacenar la información por medio de consultas que ofrecen

una amplia flexibilidad y poder para administrar la información.

Garantizar herramientas para evitar la duplicidad de registros, a través de

campos claves o llaves.

Garantizar la integridad referencial: Así al eliminar un registro elimina todos

los registros relacionados dependientes.

Favorecer la normalización por ser más comprensible y aplicable.

Facilitar la creación de bases de datos partiendo del diagrama entidad-

relación.

1.4.- TABLAS

Tabla en las bases de datos, se refiere al tipo de modelado de datos, donde se

guardan los datos recogidos por un programa. Su estructura general se

asemeja a la vista general de un programa de Hoja de cálculo.

Las tablas se componen de dos estructuras:

Registro: es cada una de las filas en que se divide la tabla. Cada registro

contiene datos de los mismos tipos que los demás registros. Ejemplo: en

una tabla de nombres y direcciones, cada fila contendrá un nombre y

una dirección.

Campo: es cada una de las columnas que forman la tabla. Contienen

datos de tipo diferente a los de otros campos. En el ejemplo anterior, un

campo contendrá un tipo de datos único, como una dirección, o un

número de teléfono, un nombre, etc.

A los campos se les puede asignar, además, propiedades especiales que

afectan a los registros insertados. El campo puede ser definido

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 6

como índice o autoincrementable, lo cual permite que los datos de ese campo

cambien solos o sean el principal indicar a la hora de ordenar los datos

contenidos.

Cada tabla creada debe tener un nombre único en la cada Base de Datos,

haciéndola accesible mediante su nombre o su seudónimo (Alias) (dependiendo

del tipo de base de datos elegida).

La estructura de las tablas viene dado por la forma de un archivo plano, los

cuales en un inicio se componían de un modo similar.

1.4.1.- TIPOS DE TABLAS

Además de la función estándar de las tablas básicas definidas por el usuario,

SQL Server proporciona los siguientes tipos de tabla, que permiten llevar a

cabo objetivos especiales en una base de datos que se utiliza para acomodar

los datos

TABLAS CON PARTICIONES

Las tablas con particiones son tablas cuyos datos se han dividido

horizontalmente entre unidades que pueden repartirse por más de un

grupo de archivos de una base de datos. Las particiones facilitan la

administración de las tablas y los índices grandes porque permiten

obtener acceso y administrar subconjuntos de datos con rapidez y

eficacia al mismo tiempo que mantienen la integridad del conjunto. En

un escenario con particiones, las operaciones como, por ejemplo, la

carga de datos de un sistema OLTP a un sistema OLAP, pueden

realizarse en cuestión de segundos en lugar de minutos u horas en otras

versiones. Las operaciones de mantenimiento que se realizan en los

subconjuntos de datos también se realizan de forma más eficaz porque

sólo afectan a los datos necesarios en lugar de a toda la tabla.

Tiene sentido crear una tabla con particiones si la tabla es muy grande o

se espera que crezca mucho, y si alguna de las dos condiciones

siguientes es verdadera:

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 7

La tabla contiene, o se espera que contenga, muchos datos que se

utilizan de manera diferente. Las consultas o las actualizaciones de la

tabla no se realizan como se esperaba o los costos de mantenimiento

son superiores a los períodos de mantenimiento predefinidos. Las tablas

con particiones admiten todas las propiedades y características

asociadas con el diseño y consulta de tablas estándar, incluidas las

restricciones, los valores predeterminados, los valores de identidad y

marca de tiempo, los desencadenadores y los índices. Por lo tanto, si

desea implementar una vista con particiones que sea local respecto a un

servidor, debe implementar una tabla con particiones. Para obtener

información para comprender, diseñar e implementar tablas con

particiones, vea Tablas e índices con particiones.

TABLAS TEMPORALES

Hay dos tipos de tablas temporales: locales y globales. Las tablas

temporales locales son visibles sólo para sus creadores durante la

misma conexión a una instancia de SQL Server como cuando se crearon

o cuando se hizo referencia a ellas por primera vez. Las tablas

temporales locales se eliminan cuando el usuario se desconecta de la

instancia de SQL Server. Las tablas temporales globales están visibles

para cualquier usuario y conexión una vez creadas, y se eliminan cuando

todos los usuarios que hacen referencia a la tabla se desconectan de la

instancia de SQL Server.

TABLAS DEL SISTEMA

SQL Server almacena los datos que definen la configuración del servidor

y de todas sus tablas en un conjunto de tablas especial, conocido como

tablas del sistema. Los usuarios no pueden consultar ni actualizar

directamente las tablas del sistema si no es a través de una conexión de

administrador dedicada (DAC) que sólo debería utilizarse bajo la

supervisión de los servicios de atención al cliente de Microsoft. Para

obtener más información, vea Usar una conexión de administrador

dedicada. Las tablas de sistema se cambian normalmente en cada

versión nueva de SQL Server. Puede que las aplicaciones que hacen

referencia directamente a las tablas del sistema tengan que escribirse de

nuevo para poder actualizarlas a una versión nueva de SQL Server con

una versión diferente de las tablas de sistema. La información de las

tablas del sistema está disponible a través de las vistas de catálogo.

Para obtener más información, vea Tablas del sistema (Transact-SQL).

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 8

Con las tablas anchas, puede crear esquemas flexibles dentro de una

aplicación. Puede agregar o quitar columnas siempre que lo desee.

Tenga presente que el uso de tablas anchas tiene consideraciones de

rendimiento únicas, como unos mayores requisitos de memoria en

tiempo de ejecución y en tiempo de compilación. Para obtener más

información, vea Consideraciones de rendimiento para las tablas anchas.

TABLAS PERSISTENTES

Son aquellas que permiten que los registros sean eliminados o borrados

manualmente y tenemos de tres tipos: Base, Vistas, Instantáneos

Base.- Es en donde se encuentra toda la información de todos los

registros sin que se haga ninguna validación adicional.

Vistas.- Es una vista o relación que se hace en referencia a una fila o

columna especifica.

Instantáneos.- Son aquellos registros que se los puede ver de

manera inmediata con solo una referencia.

1.5.- TERMINOLOGÍA DEL MODELO RELACIONAL

1.5.1.- ESQUEMA

Un esquema es la definición de una estructura (generalmente relaciones o

tablas de una base de datos), es decir, determina la identidad de la relación y

qué tipo de información podrá ser almacenada dentro de ella; en otras

palabras, el esquema son los metadatos de la relación. Todo esquema constará

de:

Nombre de la relación (su identificador).

Nombre de los atributos (o campos) de la relación y sus dominios; el dominio

de un atributo o campo define los valores permitidos para el mismo, es

equivalente al tipo de dato por ejemplo character, integer, date, string, etc.

1.5.2.- INSTANCIAS

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 9

Una instancia de manera formal es la aplicación de un esquema a un conjunto

finito de datos. En palabras no tan técnicas, se puede definir como el contenido

de una tabla en un momento dado, pero también es valido referirnos a una

instancia cuando trabajamos o mostramos únicamente un subconjunto de la

información contenida en una relación o tabla, como por ejemplo:

Ciertos caracteres y números (una sola columna de una sola fila).

Algunas o todas las filas con todas o algunas columnas

Cada fila es una tupla. El número de filas es llamado cardinalidad.

El número de columnas es llamado aridad o grado.

1.5.3.- ATRIBUTOS

Los atributos son las columnas de una relación y describen características

particulares de ella.

1.5.4.- ESQUEMAS

Es el nombre que se le da a una relación y el conjunto de atributos en ella.

1.5.5.- TUPLAS

Cada uno de los renglones en una relación conteniendo valores para cada uno

de los atributos.

1.5.6.- DOMINIOS

Se debe considerar que cada atributo (columna) debe ser atómico, es decir,

que no sea divisible, no se puede pensar en un atributo como un "registro" o

"estructura" de datos.

1.6.-CLAVES EN EL MODELO REALCIONAL

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 10

Una clave candidata de una relación es un conjunto no vacío de atributos que

identifican unívoca y mínimamente cada tupla. Por la propia definición de

relación, siempre hay al menos una clave candidata, ya que al ser la relación

un conjunto no existen tuplas repetidas y por tanto, el conjunto de todos los

atributos identificará unívocamente a las tuplas. Una relación puede tener más

de una clave candidata, entre las cuales se debe distinguir:

Clave primaria: es aquella clave candidata que el usuario escogerá, por

consideraciones ajenas al modelo relacional, para identificar a las tuplas

de una relación.

Clave alternativa: son aquellas claves candidatas que no han sido

elegidas.

Se denomina clave ajena de una relación R2 a un conjunto no vacío de

atributos cuyos valores han de coincidir con los valores de la clave

primaria de otra relación R1. La clave ajena y la correspondiente clave

primaria han de estar definidas sobre los mismos dominios.

1.7.- VALORES NULL

NULL indica que el valor es desconocido. Un valor NULL no es lo mismo que un

valor cero o vacío. No hay dos valores NULL que sean iguales. La comparación

entre dos valores NULL, o entre un valor NULL y cualquier otro valor, tiene un

resultado desconocido porque el valor de cada NULL es desconocido.

Normalmente, los valores NULL indican que los datos son desconocidos, no

aplicables o que se agregarán posteriormente. Por ejemplo, la inicial de un

cliente puede que no sea conocida en el momento en que éste hace un pedido.

A continuación se muestra información acerca de los valores NULL:

Para comprobar si hay valores NULL en una consulta, use IS NULL o IS

NOT NULL en la cláusula WHERE.

Cuando se ven los resultados de la consulta en el Editor de código de

SQL Server Management Studio, los valores null se muestran

como NULL en el conjunto de resultados.

Los valores NULL se pueden insertar en una columna si se indica

explícitamente NULL en una instrucción INSERT o UPDATE, si se deja

fuera una columna de una instrucción INSERT, o bien si se agrega una

columna nueva a una tabla existente con la instrucción ALTER TABLE.

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 11

Los valores NULL no se pueden usar en la información necesaria para

distinguir una fila en una tabla de otra fila, como, por ejemplo, las claves

principales.

1.8.- RESTRICCIONES EN EL MODELO RELACIONAL

En el modelo relacional, existen restricciones, es decir, estructuras u

ocurrencias no permitidas, siendo preciso distinguir entre restricciones

inherentes y restricciones de usuario.

1.8.1.- RESTRICCIONES INHERENTES

Además de las derivadas de la definición matemática de "relación" como eran

que:

No hay dos tuplas iguales.

El orden de las tuplas no es significativo.

El orden de los atributos (columnas) no es significativo.

Cada atributo sólo puede tomar un único valor del dominio, no

admitiéndose por tanto los grupos repetitivos.

Tenemos que la regla de integridad de entidad establece que "Ningún atributo

que forme parte de la clave primaria de una relación puede tomar un valor

nulo"; esto es, un valor desconocido o inexistente. Esta restricción debería

aplicarse también a las claves alternativas, pero el modelo no lo exige.

1.8.2.- RESTRICCIONES DE USUARIO

Podemos considerar la restricción de usuario, dentro del contexto relacional,

como un predicado definido sobre un conjunto de atributos, de tuplas o de

dominios, que debe ser verificado por los correspondientes objetos para que

éstos constituyan una ocurrencia válida del esquema.

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 12

Dentro de las restricciones de usuario destaca la restricción de integridad

referencial que dice que los valores de clave ajena deben coincidir con los de

clave primaria asociada a ella o ser nulos.

La integridad referencial es una restricción de comportamiento ya que viene

impuesta por el mundo real y es el usuario quien la define al describir el

esquema relacional; es también de tipo implícito, ya que se define en el

esquema y el modelo la reconoce (o así algunos productos) sin necesidad de

que se programe ni de que se tenga que escribir ningún procedimiento para

obligar a que se cumpla.

EDITORIAL (NOMBRE_E, DIRECCION, CIUDAD, PAIS)

LIBRO (CODIGO, TITULO, IDIOMA, ..., NOMBRE_E)

En este ejemplo el atributo nombre_e de la relación LIBRO es clave ajena que

referencia a EDITORIAL, de modo que debe concordar con la clave primaria de

la relación EDITORIAL o bien ser nulo, porque los libros de nuestra base de

datos deberán pertenecer a una editorial existente, o si se desconoce la

editorial, no se tendrá ningún valor para este atributo.

AUTOR (NOMBRE, NACIONALIDAD, INSTITUCION, ..)

LIBRO (CODIGO, TITULO, IDIOMA, EDITORIAL, ...)

ESCRIBE (NOMBRE, COD LIBRO)

En este ejemplo la relación ESCRIBE posee dos claves ajenas: nombre, que

referencia a la relación AUTOR, y COD_LIBRO, que referencia a la relación

LIBRO; en este caso ninguna de las dos claves ajenas puede tomar valores

nulos, ya que forman parte de la clave primaria de la relación ESCRIBE.

Además de definir las claves ajenas, hay que determinar las consecuencias que

pueden tener ciertas operaciones (borrado y modificación) realizadas sobre

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 13

tuplas de la relación referenciada; pudiéndose distinguir, en principio, las

siguientes opciones:

Operación restringida: esto es, el borrado o la modificación de tuplas de

la relación que contiene la clave primaria referenciada; sólo se permite

si no existen tuplas con dicha clave en la relación que contiene la clave

ajena. Esto nos llevaría, por ejemplo, a que para poder borrar una

editorial de nuestra base de datos no tendría que haber ningún libro que

estuviese publicado por dicha editorial, en caso contrario el sistema

impediría el borrado.

Operación con transmisión en cascada: esto es, el borrado o la

modificación de tuplas de la relación que contiene la clave primaria

referenciada lleva consigo el borrado o modificación en cascada de las

tuplas de la relación que contienen la clave ajena. En nuestro ejemplo,

equivaldría a decir que al modificar el nombre de una editorial en la

relación EDITORIAL, se tendría que modificar también dicho nombre en

todos los libros de nuestra base de datos publicados por dicha editorial.

Operación con puesta a nulos: esto es, el borrado o la modificación de

tuplas de la relación que contiene la clave primaria referenciada lleva

consigo poner a nulos los valores de las claves ajenas de la relación que

referencia. Esto nos llevaría a que cuando se borra una editorial, a los

libros que ha publicado dicha editorial y que se encuentran en la relación

LIBROS se les coloque el atributo nombre_e a nulos. Esta opción,

obviamente, sólo es posible cuando el atributo que es clave ajena

admite el valor nulo.

Operación con puesta a valor por defecto: esto es, el borrado o la

modificación de tuplas de la relación que contiene la clave primaria

referenciada lleva consigo poner el valor por defecto a la clave ajena de

la relación que referencia.

Operación que desencadena un procedimiento de usuario: en este caso,

el borrado o la modificación de tuplas de la tabla referenciada pone en

marcha un procedimiento definido por el usuario.

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 14

1.9.- LAS 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, diseñado para definir qué

requiere un sistema de administración de base de datos.

Codd se percató de que existían bases de datos en el mercado las cuales

decían ser relacionales, pero lo único que hacían era guardar la información en

las tablas, sin estar estas tablas literalmente normalizadas; entonces éste

publicó 12 reglas que un verdadero sistema relacional debería tener aunque en

la práctica algunas de ellas son difíciles de realizar. Un sistema podrá

considerarse "más relacional" cuanto más siga estas 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 información, toda la información en la base de datos es

representada unidireccionalmente, por valores en posiciones de las

columnas dentro de filas de tablas. Toda la información en una base

de datos relacional se representa explícitamente en el nivel lógico

exactamente de una manera: con valores en tablas.

Regla 2:

La regla del acceso garantizado, todos los datos deben ser accesibles

sin ambigüedad. Esta regla es esencialmente una nueva exposición

del requisito fundamental para las llaves primarias. Dice que cada

valor escalar individual en la base de datos debe ser lógicamente

direccionadle especificando el nombre de la tabla, la columna que lo

contiene y la llave primaria.

Regla 3:

Tratamiento sistemático de valores nulos, el sistema de gestión de

base de datos debe permitir que haya campos nulos. Debe tener una

representación de la "información que falta y de la información

inaplicable" que es sistemática, distinto de todos los valores regulares.

Regla 4:

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 15

Catálogo dinámico en línea basado en el modelo relacional, el sistema

debe soportar un catálogo en línea, el catálogo relacional debe ser

accesible a los usuarios autorizados. Es decir, los usuarios deben

poder tener acceso a la estructura de la base de datos (catálogo).

Regla 5:

La regla comprensiva del sub lenguaje de los datos, el sistema debe

soportar por lo menos un lenguaje relacional que:

Tenga una sintaxis lineal.

Puede ser utilizado recíprocamente y dentro de programas

de uso.

Soporte operaciones de definición de datos, operaciones de

manipulación de datos (actualización así como la

recuperación), seguridad e integridad y operaciones de

administración de transacciones.

Regla 6:

Regla de actualización, todas las vistas que son teóricamente

actualizables deben ser actualizables por el sistema.

Regla 7:

Alto nivel de inserción, actualización, y cancelación, 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 múltiples y/o de tablas múltiples.

Regla 8:

Independencia física de los datos, los programas de aplicación y

actividades del terminal permanecen inalterados a nivel lógico

cuandoquiera que se realicen cambios en las representaciones de

almacenamiento o métodos de acceso.

Regla 9:

Independencia lógica de los datos, los cambios al nivel lógico (tablas,

columnas, filas, etc.) no deben requerir un cambio a una solicitud

basada en la estructura. La independencia de datos lógica es más

difícil de lograr que la independencia física de datos.

Regla 10:

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 16

Independencia de la integridad, las limitaciones de la integridad se

deben especificar por separado de los programas de la aplicación 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 distribución, la distribución 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:

cuando una versión distribuida del SGBD se introdujo por

primera vez

cuando se distribuyen los datos existentes se redistribuyen

en todo el sistema.

Regla 12:

La regla de la no subversión, si el sistema proporciona una interfaz

de bajo nivel de registro, a parte de una interfaz relacional, que esa

interfaz de bajo nivel no se pueda utilizar para subvertir el sistema,

por ejemplo: sin pasar por seguridad relacional o limitación

de integridad. Esto es debido a que existen sistemas anteriormente

no relacionales que añadieron una interfaz relacional, pero con la

interfaz nativa existe la posibilidad de trabajar no relacionalmente.

1.10.- TIPOS DE RELACIONES EN UN MODELO ENTIDAD-RELACION

Se pueden distinguir tres tipos de relaciones:

Relación Uno a Uno:

Cuando un registro de una tabla sólo puede estar relacionado con un

único registro de la otra tabla y viceversa.

Por ejemplo: tenemos dos tablas una con los datos de diferentes

poblaciones y otra con una lista de Alcaldes, una población sólo puede

tener un alcalde, y un alcalde lo será únicamente de una población.

Alcalde Población

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 17

Relación Uno a Varios:

Cuando un registro de una tabla (tabla secundaria) sólo puede estar

relacionado con un único registro de la otra tabla (tabla principal) y un

registro de la otra tabla (tabla principal) puede tener más de un registro

relacionado en la primera tabla (tabla secundaria).

Por ejemplo: tenemos dos tablas una con los datos de diferentes

poblaciones y otra con los habitantes, una población puede tener más de

un habitante, pero un habitante pertenecerá (estará empadronado) en

una única población.

Relación Varios a Varios:

Cuando un registro de una tabla puede estar relacionado con más de un

registro de la otra tabla y viceversa.

Por ejemplo: tenemos dos tablas una con los datos de clientes y otra con

los artículos que se venden en la empresa, un cliente podrá realizar un

pedido con varios artículos, y un artículo podrá ser vendido a más de un

cliente.

Las relaciones varios a varios se suelen representar definiendo una tabla

intermedia entre las dos tablas. Siguiendo el ejemplo anterior sería

definir una tabla líneas de pedido relacionado con clientes y con

artículos.

1.11.- EJEMPLO DE UN MODELO RELACIONAL MEDIANTE ESQUEMA Y

CODIFICACIÓN SQL SERVER 2005

Para el siguiente ejemplo se considerara una base de datos de una empresa

dedicada a la entrega de pedidos (productos) puede ser Servientrega u otra.

Población Habitantes

Cliente Articulo

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 18

PK= PRIMARY KEY

FK= FORREING KEY

1.11.1.- CODIFICACIÓN EN SQL SERVER 2005

CREACION DE LA BASE DE DATOS

create database Empresa_Entrega

go

use Empresa_Entrega

CREACION DE LA TABLA CLIENTES

create table Clientes(

IdClientes int identity(1,1) not null,

NombreCompañia nvarchar(20) not null,

NombreContacto nvarchar(20) not null,

Ciudad nvarchar(10) not null,

Telefono char(10),

constraint pk_clie primary key (IdClientes),

)

CREACIÓN DE LA TABLA EMPLEADOS

create table Empleados(

IdEmpleado int identity (100,1) not null,

Apellidos nvarchar(20) not null,

Nombre nvarchar(15) not null,

Cargo nvarchar(15) not null,

FechaContratacion smalldatetime not null,

Ciudad nvarchar(15) not null,

Telefono char(10) not null,

constraint pk_emp primary key(IdEmpleado),

Clientes PK. IdClientes NombreCompañia NombreContacto Ciudad Teléfono

Empleados PK. IdEmpleado Apellidos Nombre Cargo FechaContratacion Ciudad Teléfono

Pedidos PK. IdPedido FK. IdClientes FK. IdEmpleado FechaPedido FechaEntrega FechaEnvio Cargo Destinatario CiudadDestinatario

Detalles de pedidos FK. IdPedido FK. IdProducto PrecioUnidad Cantidad Descuento

Productos PK. IdProducto NombreProducto CantidadUnitaria PrecioUnidad

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 19

)

CREACIÓN DE LA TABLA PRODCUTOS

create table Productos(

IdProducto int identity(200,1) not null,

NombreProducto nvarchar(30) not null,

CantidadUnitaria int not null,

PrecioUnidad real not null,

constraint pk_prod primary key(IdProducto),

)

CREACIÓN DE LA TABLA DETALLES_DE_PEDIDOS

create table Detalles_de_pedidos(

IdPedido int not null,

IdProducto int not null,

PrecioUnidad real not null,

Cantidad int not null,

Descuento real not null,

)

CREACIÓN DE LA TABLA PEDIDOS

create table Pedidos(

IdPedido int identity(400,1) not null,

IdClientes int not null,

IdEmpleado int not null,

FechaPedido smalldatetime not null,

FechaEntrega smalldatetime not null,

FechaEnvio smalldatetime not null,

Cargo nvarchar(20) not null,

Destinatario nvarchar(20) not null,

CiudadDestinatario nvarchar(20) not null,

constraint pk_ped primary key(IdPedido),

)

ESTABLECIENDO CLAVES FORANEAS EN LA TABLA

DETALLES_DE_PEDIDOS

alter table Detalles_de_pedidos add foreign key(IdPedido) references

Pedidos (IdPedido)

alter table Detalles_de_pedidos add foreign key(IdProducto) references

Productos (IdProducto)

ESTABLECIENDO CLAVES FORANEAS EN LA TABLA PEDIDOS

alter table Pedidos add foreign key (IdClientes) references Clientes

(IdClientes)

alter table Pedidos add foreign key (IdEmpleado) references Empleados

(IdEmpleado)

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 20

Ilustración 1. Explorador de Objetos en SQL Server 2005. Vista de las tablas

SEMINARIO DE PUNTO NET

MODELO RELACIONAL

Grupo de trabajo Página 21

2.- CONCLUSIÓN

El poder conocer el verdadero funcionamiento de un modelo relacional, dentro

de una base de datos que maneje cualquier entidad o empresa, es bastante

fundamental para la buena disposición de los datos.

Como se ha podido observar, este modelo consta de una base de datos

relacional, la cual involucra la comunicación efectiva entre las tablas. Es

importante destacar que un buen modelo se debe de basar en ciertas reglas

que hagan del mismo más eficiente y útil. Además un modelo relacional

está basado en la lógica de predicados y en la teoría de conjuntos, lo cual da a

conocer la necesidad de tener amplios conocimientos en los temas

anteriormente mencionados y la realización de un mal modelo, conlleva al mal

funcionamiento de la base de datos.