Está en la página 1de 10

Ao de la Promocin de la Industria Responsable y del Compromiso Climtico

Profesor:
Ing. Giscard Marquez Valverde

Alumno:

Damarys Arevalo Talledo


Benites Ortiz, Oholger

Curso:
Base de Datos I

Ciclo:
III

Talara Per
2014

Concepto de relacin.Las relaciones son un tema complejo pero veamos un sencillo ejemplo con las tablas Alumnos y
Cursos para entenderlo mucho mejor. Inicialmente nuestras tablas estaran definidas del
siguiente modo:

En la tabla Alumnos tenemos toda la informacin que necesitamos sobre nuestros alumnos
como:
Su nmero de expediente.
Su nombre y apellidos.
Su fecha de nacimiento.
El grupo al que pertenece el alumno.
La ubicacin del grupo, es decir, el aula donde estn los alumnos de ese grupo (Primera planta,
edificio anexo, etctera).
Cualquier tipo de comentario de inters: grupo de compensatoria, apoyo, etctera.
Para la tabla Grupos nos podamos conformar con la denominacin del grupo (1A, 1B, 3A...) pero
le hemos aadido algunos datos que nos pueden resultar de inters:
Nmero total de alumnos que tiene el grupo.
El lugar donde se encuentra ubicado: Aula de msica, Aula 205 Edificio principal, etctera.
Cualquier otro dato de inters: Compensatoria, grupo de apoyo, etctera.
Sin saber nada de bases de datos y de relaciones podemos, darnos cuenta que al comprobar los
datos incluidos en las tablas de Alumnos y Grupos existe informacin que se repite en ambas:

Esta situacin no es demasiado favorable cuando trabajamos con bases de datos donde
habitualmente la cantidad de informacin que se maneja es importante. La solucin pasa por
RELACIONAR las tablas con informacin coincidente de modo que no exista duplicidad de
informacin. Todo esto, traducido a un lenguaje ms natural sera: "Para qu escribir dos veces
lo mismo, si puedo hacerlo una sola y trabajar del mismo modo".

Volviendo a nuestro ejemplo, si relacionamos las tablas Alumnos y Grupos mediante el nombre
del grupo sera suficiente con indicar en la tabla Alumnos este valor para obtener el nmero de
alumnos del grupo, su ubicacin y las posibles observaciones:

Esquema de la Base de Datos


El esquema de una base de datos, describe la estructura de una base de datos, en un lenguaje
formal soportado por un sistema de gestin de base de datos (DBMS). En una base de datos
relacional, el esquema define sus tablas, sus campos en cada tabla y las relaciones entre cada
campo y cada tabla.
El esquema es generalmente almacenado en un diccionario de datos. Aunque generalmente el
esquema es definido en un lenguaje de base de datos, el trmino se usa a menudo para
referirse a una representacin grfica de la estructura de base de datos.
Niveles de esquema de base de datos:
Esquema Conceptual, un mapa de conceptos y sus relaciones.
Esquema Lgico, un mapa de las entidades y sus atributos y las relaciones.
Esquema Fsico, una aplicacin de un esquema lgico.
Esquema Objeto, Base de datos Oracle Objeto.

Instancia de la Base de Datos


Cuando comenzamos a trabajar con Oracle una de las primeras cosas que aprendemos es a
diferenciar entre estos conceptos: base de datos, instancia e instancia de base de datos.
Una instancia es el conjunto de procesos que se ejecutan en el servidor as como la memoria
que comparten para ello.
Cuando se habla de base de datos, nos referimos a los archivos fsicos que componen nuestra
base de datos.

Si queremos referirnos a los procesos que se ejecutan en memoria como a los archivos de base
de datos tendremos que utilizar el trmino instancia de base de datos.
La instancia en Oracle describe varios procesos residentes en la memoria del computador(es) y
un rea de memoria compartida por aquellos procesos. En arquitecturas de bases de datos tales
como, Microsoft SQL Server y IBM BD2, la palabra instancia indica una coleccin de bases de
datos que comparten recursos de memoria en comn, o sea, la relacin entre instancia y bases
de datos es 1 a N. Pero la relacin entre la instancia de Oracle y la base de datos es 1 a 1 o n a 1.
Cuando hay una relacin N a 1, la configuracin es llamada RAC (Real Application CLuster),
donde la base de datos reside en discos compartidos y las instancias en mltiples computadores
anexados a la base de datos.
La instancia de Oracle es el motor que procesa los requerimientos de datos desde la base de
datos. Est compuesta por procesos en primer plano, en segundo plano y un rea de memoria
compartida (SGA).

Una instancia de Oracle es un conjunto de estructuras de memoria que estn asociadas con los
archivos de datos(datafiles) en una mquina. Una base de datos (database) es una coleccin de
archivos fsicos.
INSTANCIA DE ORACLE
La integran los procesos 'background' y la SGA
Abre una y slo una BDO, y permite acceder a ella.
Nota: con Oracle Real Application Cluster (RAC), ms de una instancia usarn la misma BD.
En la mquina donde reside el servidor Oracle, la variable ORACLE_SID identifica a la instancia
con la que estamos trabajando.

Restricciones de Integridad o Integridad referencial


Una vez definida la estructura de datos del modelo relacional, pasamos a estudiar las reglas de
integridad, es decir que los datos almacenados en dicha estructura deben cumplir ciertas
caractersticas para garantizar que son correctos. Al definir cada atributo sobre un dominio se
impone una restriccin sobre el conjunto de valores permitidos para cada atributo.
A este tipo de restricciones se les denomina restricciones de dominios. Hay adems dos reglas
de integridad muy importantes que se deben cumplir en todas las bases de datos relacionales y
en todos sus estados o instancias (las reglas se deben cumplir todo el tiempo). Estas reglas son
la regla de integridad de entidades y la regla de integridad referencial. Antes de definirlas, es
preciso conocer el concepto de nulo.
Restricciones de dominios
Imponen una limitacin al conjunto de valores permitidos para los atributos en las relaciones.
Permitiendo restringir los valores que puede tomar un atributo respecto a su dominio, por
ejemplo EDAD >= 18.
Nulos
Cuando en una tupla un atributo es desconocido, se dice que es nulo. Un nulo no representa el
valor cero ni la cadena vaca, stos son valores que tienen significado. El nulo implica ausencia
de informacin, bien porque al insertar la tupla se desconoca el valor del atributo, o bien porque
para dicha tupla el atributo no tiene sentido.
Ya que los nulos no son valores, deben tratarse de modo diferente, lo que causa problemas de
implementacin en los SGBD relacionales.
NULL|NOT NULL. Determina si se permiten valores NULL en la columna.
ORACLE: El optimizador necesita saber que una columna no es NOT NULL, y sin este
conocimiento, se limita a elegir un plan de ejecucin inferior al ptimo.
SQL SERVER: NULL no es estrictamente una restriccin, pero se puede especificar de la misma
forma que NOT NULL. La restriccin se puede usar para las columnas calculadas slo si se
especifica tambin PERSISTED.
MySQL 5.02 Si la columna puede tener NULL como valor, la columna se define con una clusula
DEFAULT NULL explcita. En caso contrario no define DEFAULT explcito.

El proceso de diseo de bases de datos

El proceso para el diseo de una base de datos son los siguientes:


Determinar la finalidad de la base de datos: esto le ayudara a estar preparado para los dems
pasos.
Buscar y organizar la informacin necesaria: rena todos los tipos de informacin que desee
registrar en la base como los nombres de productos o los nmeros de pedidos.
Dividir la informacin en tablas: Divida lo elementos de informacin e entidades o temas
principales como, productos o pedidos. Cada tema pasara a ser una tabla.
Convertir los elementos de informacin en columnas: Decida que informacin desea almacenar
en cada de tabla. Cada elemento se convertir en un campo y se mostrara como una columna
en la tabla.
Especificar claves principales: Elia al clave principal de la tabla. Lac lave principal es una columna
que se utiliza para identificar equivocadamente cada fila, como id.
Definir relaciones entre las tablas: Examine cada tabla y decida cmo se relacionan los datos de
una tabla con las dems tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar
las relaciones segn sea necesario
Ajustar el diseo: Analice el diseo para detectar errores. Cree las tablas y agregue algunos
registros con datos de ejemplo. Compruebe si puede obtener los resultados previstos de las
tablas. Realice los ajustes necesarios en el diseo.
Aplicar las reglas de normalizacin: Aplique las reglas de normalizacin de los datos para
comprobar si las tablas estn estructuradas correctamente. Realice los ajustes necesarios en las
tablas.

Paso del modelo E/R al modelo relacional


Vamos a ver cmo convertir del modelo entidad-relacin simple (llammosle as para
diferenciarlo del extendido) al modelo relacional. Para ello simplemente debemos aplicar el
siguiente cuadro:

MODELO ENTIDAD/RELACIN
Entidad
Atributo
Identificador nico
Relaciones N:M

Relaciones 1:M

Relaciones 1:1

MODELO RELACIONAL
Tabla
Columna/Campo
Clave Primaria
Nueva tabla con clave
primaria la concatenacin de
las claves de las entidades que
la forman (la relacin pasa a
ser una tabla, y en esa tabla se
pone como C.A. las entidades
que une)
Transformar la relacin en una
tabla si no todos los
elementos de la entidad que
participa con muchos tienen
asociado un elemento de la
entidad que participa con uno.
Propagando la de 1 en la de
muchos (creando un campo
en la de muchos que
referencie a la de 1) si cada
elemento de la entidad que Esta diferenciacin se debe a
participa con muchos aparece que todas las claves ajenas
en la entidad de uno, es decir, deben hacer referencia a las
si TODOS los elementos de la claves primaria de otras tablas
entidad de muchos tienen
y consecuentemente no
asociado uno de la entidad de pueden ser nulas. Dicho de otra
uno
manera, toda referencia ajena
Transformar la relacin en debe hacerse a un campo nico
tabla si no todos los
elementos de la entidad que
participa con muchos tienen
asociado un elemento de la
entidad que participa con uno.
Propagar la clave (igual que en
la de 1:M) si cada elemento de
la entidad que participa con
muchos aparece en la entidad
de uno, es decir, si TODOS los
elementos de la entidad de
muchos tienen asociado uno
de la entidad de uno

Ejemplo:
Ejemplo: transformar el esquema entidad/relacin al modelo relacional de una tienda de
antigedades
Tienda de antigedades

En este ejemplo observamos como tenemos dos entidades (cada una con cuatro atributos) y
una relacin 1:M en la que no todos los artculos deben ser comprados por un cliente sino que
daremos de alta el artculo, a la espera de ser comprado por un cliente, pudiendo existir artculos
en stock que no han sido vendidos nunca. Esta relacin posee dos atributos propios de la
entidad. Tal como vimos en la tabla la solucin consistir en tres tablas al no ser una relacin
obligatoria, una por cada entidad (clientes y artculos) y otra para la relacin. As, nos quedaran
las siguientes tablas
CLIENTE:{(TELFONO: numrico), (DIRECCIN: texto), (COD.CLIENTE: numrico), (NOMBRE:
texto)}
ARTCULOS:{(STOCK:
numrico),
(DENOMINACIN:
texto),
(PRECIO:
numrico),
(COD.ARTCULO: numrico)}
COMPRA:{_CP____(CLIENTE:Numrico),(ARTCULO:
Numrico)____CP_,(FECHA_VENTA:
Fecha),(UNID_VENDIDAS: Numrico)}
COMPRA --> CLIENTE --> CLIENTE
COMPRA --> ARTCULO --> ARTCULOS
Las claves (principales y ajenas) aparecen subrayadas y las claves de la tabla COMPRA aparecen
doblemente subrayadas (o eso he intentado ya que no encontr esa posibilidad en el editor de
texto que uso). Cmo se pueden distinguir? A travs del diagrama referencial, en donde
podemos leer que en la tabla COMPRAS, el campo CLIENTE hace referencia a la tabla CLIENTES
y en la misma tabla COMPRAS, el campo ARTCULOS hace referencia a la tabla ARTCULOS. Las
claves subrayadas que no aparezcan en este diagrama referencial (COD.CLIENTE y
COD.ARTCULO) se suponen claves principales al igual que las claves doblemente subrayadas.
Veamos otro ejemplo. Es similar al anterior solo que en este caso la relacin es obligatoria

Vuelve a darse el caso de dos entidades y una relacin 1 a muchos. Es el mismo caso que antes
pues suponemos que todos los libros tienen un tema. Las tablas y el diagrama referencial seran:
TEMAS:{(DESCRIPCIN: texto), (COD.TEMAS: numrico)}
LIBROS:{(TTULO: texto), (AUTOR: texto), (NUM_EJEMPLARES: numrico), (COD.LIBRO:
numrico), (ISBN: numrico), (CA.COD.TEMAS: numrico)}
LIBROS --> C.A.COD.TEMAS --> TEMAS
Veamos ahora otro ejemplo en el que cambia la relacin a 1:1

En este caso cul de las dos entidades incrustamos en la otra? La respuesta es "da igual". sta
es la solucin propuesta
EMPLEADO:{(COD.EMP: numrico), (NOMBRE: texto), (TLF: numrico), (SALARIO: numrico)}
PUESTO_DE_TRABAJO:{(COD.TRA: numrico), (DEPT: texto), (C.A.COD.EMP: numrico)}
PUESTO_DE_TRABAJO --> C.A.COD.EMP. --> EMPLEADO
Hemos insertado al EMPLEADO en la tabla del PUESTO DE TRABAJO.
Finalmente vemos un ejemplo de una relacin M:M

En este caso de una relacin N:M creamos una tabla independiente quedando:
ALUMNOS:{(NOMBRE: Texto),(DNI: Numrico),(DIRECCIN: Texto),(TELFONO: Numrico)}
CURSO:{(CDIGO: Numrico),(DENOMINACIN: Texto),(PROFESOR: Texto)}
MATRCULA:{_CP____(ALUMNO: Numrico),(CURSO: Numrico)____CP_}

También podría gustarte