Modelo relacional

2012

UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS ADMINISTRATIVAS
ING. EN SISTEMAS ADMINISTRATIVOS COMPUTARIZADOS

GRUPO DE TRABAJO:
 SALINAS VARAS NELSON
 TORRES AGURTO MICHELLE
 CARRASCO TRIVIÑO JEAN
 LOPEZ OROZCO MIGUEL

SEMINARIO DE PUNTO NET

ING. CEDEÑO

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

MODELO RELACIONAL

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

Grupo de trabajo Página 1

MODELO RELACIONAL

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


MODELO RELACIONAL

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 1968 - 1970 ↔ Surge el modelo

R

E 1970 . . . ↔ Desarrollos teóricos

R 1973 - 1978 ↔ Prototipos (Ingres,
sistema R, etc. . .)
E
1978 ↔ QBE
L

A
R
C
E
I
L
O
A
N
C
A
I
L
O
1979 ↔ Oracle
N
1980 ↔ Ingres
A
1981 ↔ SQL
L
1982 ↔ DB2

1986 ↔ SQL/ ANS


MODELO RELACIONAL

1987 ↔ SQL ISO (9075)

1989 ↔ SQL Adendum

1989 ↔ Manifiesto de los SGBO

1990 ↔ Modelo Relacional Versión 2

P 1990 ↔ Manifiesto de los SGBO- 3G

O
1992 ↔ SQL 92
S

T 1995 ↔ 3er Manifiesto

R ↔
1999 SQL 3
E

L

A

C

I

O

N

A

L

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).


MODELO RELACIONAL

 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


MODELO RELACIONAL

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:


MODELO RELACIONAL

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).


MODELO RELACIONAL

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


MODELO RELACIONAL

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


MODELO RELACIONAL

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.


MODELO RELACIONAL

 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.


MODELO RELACIONAL

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


MODELO RELACIONAL

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.


MODELO RELACIONAL

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:


MODELO RELACIONAL

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:


MODELO RELACIONAL

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


MODELO RELACIONAL

 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.

Población Habitantes

 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.

Cliente Articulo

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.


MODELO RELACIONAL

Clientes Detalles de pedidos
PK. IdClientes FK. IdPedido
NombreCompañia FK. IdProducto
NombreContacto PrecioUnidad
Ciudad Cantidad
Descuento
Teléfono Pedidos
PK. IdPedido
FK. IdClientes
FK. IdEmpleado
FechaPedido
FechaEntrega
FechaEnvio Productos
Empleados Cargo PK. IdProducto
PK. IdEmpleado Destinatario NombreProducto
Apellidos CiudadDestinatario CantidadUnitaria
Nombre PrecioUnidad
Cargo PK= PRIMARY KEY
FechaContratacion FK= FORREING KEY
Ciudad
Teléfono

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),


MODELO RELACIONAL

)

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)


MODELO RELACIONAL

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


MODELO RELACIONAL

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.


Modelo relacional

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Modelo relacional

Ähnlich wie Modelo relacional (20)

Mehr von Nelson Salinas

Mehr von Nelson Salinas (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Modelo relacional