Introduccin

Esta investigacin que hemos realizado con la finalidad de aprender ms sobre

lo que es la materia de diseo de base de datos donde podemos hablar de lo
que trata dicha materia, en este documento podemos encontrar los temas
desde de la sesin 1 a la sesin 7 los cuales ya hemos visto en lo que fue el
primer parcial.

Estos temas nos hablan de cmo debemos ir modelando nuestra base de datos
lo que es la creacin de tablas con sus distintas entidades, atributos, dominios,
relaciones y con sus respetivas claves.

Ya que al realizar una tabla debemos tener bien definido lo que va a llevar
dicha tabla al momento de ser creada como va ser su relacin con algn otra,
en esto tiene ver mucho lo que es la cardinalidad ya que uno de los temas
tratados en este documento, una base de datos en si es un almacn donde
podemos guardar cualquier dato o informacin que necesite el usuario o
empresa que requiera implementarla hoy en da la mayora de empresas ya
sean grandes, medianas y pequeas utilizan lo que es una base de datos.
 1. SESIN # 1
1.1. DEFINICIN DE UN MODELO DE DATOS
Un modelo de datos es un sistema formal y abstracto que permite describir los datos
de acuerdo con reglas y convenios predefinidos o podramos decir que es un conjunto
de concepto que permiten describir, a distintos niveles de abstraccin, la estructura
de una base de datos. (segn cood)

Es un conjunto de conceptos que nos permiten describir los datos, las relaciones que
existen entre ellos, la semntica y las restricciones de consistencia.

1.2. COMPONEBTES DE MODELOS DE DATOS

El resultado de un modelado de datos es una representacin que tiene dos
componentes: las propiedades estticas se definen en un esquema y las propiedades
dinmicas se definen como especificaciones de transacciones, consultas e informes.

Propiedades estticas: entidades (u objetos), propiedades (o atributos)12 de esas

entidades, y relaciones entre esas entidades.

Propiedades dinmicas: operaciones sobre entidades, sobre propiedades o relaciones

entre operaciones.

1.2.1. Propiedades estticas

La esttica de un modelo de datos est compuesta por elementos permitidos y
elementos no permitidos.

Elementos permitidos: No son los mismos para todos los modelos de datos. Varan
especialmente en su terminologa, en general suele ser objetos que pueden ser
entidades relaciones, registros, asociaciones entre objetos.

Elementos no permitidos: No todos los valores, cambios de valor o estructuras estn

permitidas en el mundo real, adems de cada modelo de datos tambin impone por
s mismo limitaciones a las estructuras que permite. Se denomina restricciones
inherentes.

Los archivos contenidos en esta base de datos solo son de lectura, y se pueden
guardar, pero sin usar, o usarlas un tiempo despus, un ejemplo de estas serias
bibliotecas, peridicos (para almacenar informacin y si se requiere consultarla tiempo
despus).
1.2.2. Propiedades dinmicas
Los valores que toman los distintos objetos de un esquema en un determinado
momento Ti reciben el nombre de ocurrencia de esquema o estado de los datos en el
momento BDi.

En otro momento Tj la ocurrencia ser BDj.

La aplicacin de una operacin a una ocurrencia de un esquema trasforma est en

otra ocurrencia.

Estas son las ms usadas, ya que como su nombre lo indica son dinmicas, es decir,
que se usan constantemente, ya sea modificando o consultando la base de datos,
ejemplos de esta seria de tiendas, negocios, farmacia, en universidades (para los
alumnos), etc.

1.3. TIPOS DE MODELOS DE DATOS

1.3.1. Modelo Externo
Modelos externos o lgicos basados en objetos: nos permite representar los datos que
necesita cada usuario con las estructuras propias del lenguaje de programacin que
se vaya a usar. Persiguen satisfacer las necesidades de los usuarios.

1.3.2. Modelos Globales

Modelos globales o lgicos basados en registros: ayuda a escribir los datos para el
conjunto de usuarios. busca optimizar los recursos de informacin de las
organizaciones en su conjunto.

1.3.3. Modelos Internos

sirven para construir el esquema fsico o interno, est orientado a la mquina.
 SESIN # 2

1.4. METODOLOGA DEL DISEO DE BASE DE DATOS

1.4.1. Definicin de metodologa de diseo y desarrollo de B.D
El propsito es ayudar al diseador de la base de datos en lo que es planificacin,
gestin, control y evaluacin de los proyectos, mediante una serie de fases cada una
con sus respectivos pasos.

El diseo de una base de datos es un proceso complejo que abarca decisiones a muy
distintos niveles. La complejidad se controla mejor si se descompone el problema en
subproblemas y se resuelve cada uno de estos subproblemas independientemente,
utilizando tcnicas especficas. As, el diseo de una base de datos se descompone
en diseo conceptual, diseo lgico y diseo fsico.

comprende una serie de actividades a cumplir, en un orden especfico.

Una metodologa no es una camisa de fuerza, sino una referencia de un camino
a seguir.
Una metodologa puede ser adaptable de acuerdo a la naturaleza del
proyecto.
1.4.2. Diseo Conceptual
Es la construccin de un modelo que represente todos los datos utilizados en una
organizacin independientemente de las consideraciones fsicas. Se utilizan para
representar la realidad a un alto nivel de abstraccin. Mediante los modelos
conceptuales se puede construir una descripcin de la realidad fcil de entender.

Se utiliza para la abstraccin de la base de datos, para construir una descripcin para
entender en la realidad.
1.4.3. Diseo Lgico
Construir un modelo de la organizacin basados en un modelo de datos especficos,
relacionar el modelo conceptual con el lgico.

Es una descripcin de la estructura de la base de datos en trminos de las estructuras

de datos que puede procesar un tipo de SGBD (SISTEMA DE GESTION DE BASE DE
DATOS). Un modelo lgico es un lenguaje usado para especificar esquemas lgicos
(modelo relacional, modelo de red, etc.). El diseo lgico depende del tipo de SGBD
que se vaya a utilizar, no depende del producto concreto.

1.4.4. Diseo Fsico

Generar de cmo va a ser la implementacin de la base de datos dependiendo de
la el SGBD que se vaya a utilizar.

Es una descripcin de la implementacin de una base de datos en memoria

secundaria: las estructuras de almacenamiento y los mtodos utilizados para tener un
acceso eficiente a los datos. Por ello, el diseo fsico depende del SGBD concreto y el
esquema fsico se expresa mediante su lenguaje de definicin de datos.

Es una implementacin de una base de datos en las estructuras de almacenamiento

y los mtodos eficiente a los datos. Depende del SGBD concreto, y se expresa de una
manera ms detallada (atributos, relaciones, etc.).
 2. SESIN # 3
2.1. INTRODUCCIN
2.2. Componentes Estticos
2.2.1. Entidad
Es una clase generalizada de personas, lugares o cosas (objetos), para los cuales se
recopilan, almacenan y mantienen datos.

Es un grupo de tems que tienen las mismas caractersticas o atributos.

Ejemplo:

EMPLEADO

Id_empleado

Nombre

apellido

cedula

EN ESTE EJEMPLO LA ENTIDAD TIENE EL NOMBRE DE EMPLEADO

2.2.2. Atributo
Es una caracterstica de una entidad. El valor especifico de un atributo, conocido
como elemento de datos, se puede encontrar con los campos de registro que
describe una entidad. Como ya se plante, un conjunto de campos de un objeto
especfico representa un registro. Cuna clave es un campo o grupo de campos en un
registro que se utiliza para identificar a este.

son las propiedades que describen a cada entidad en un conjunto de entidades. Un

conjunto de entidades dentro de una entidad, tiene valores especficos asignados
para cada uno de sus atributos, de esta forma, es posible su identificacin unvoca.

Es una caracterstica de una entidad, conocido como elemento de datos (valor

especfico) para cada uno de sus atributos que se encuentran en los campos de un
registro que describen a una entidad y as ser posible su identificacin nica.

EMPLEADO

Id_empleado

Nombre

apellido

cedula

En este ejemplo los atributos son Id_empleado, nombre apellido, cedula, etc.

Los campos obligatorios deben ir con asterisco (*) dependiendo si son campos los
cuales no pueden ser nulos y vamos a necesitar datos de esos campos para bsqueda
en la base de datos.
2.2.3. Dominio
No es ms que un tipo de dato, que puede ser definido por el sistema, como Integer o
char o, uno ms complejo definido por el usuario. La importancia de los dominios
radica en que cuando se desea realizar una relacin entre dos o ms tablas, las claves
por las que se relacionan deben pertenecer forzosamente al mismo dominio.

2.2.4. Relacin
Las relaciones son representadas por tablas, donde cada fila de la tabla representa
una nica tupla y donde cada valor de cada atributo forma una columna.
Corresponde a una fila de una tabla (el que conocamos como registro en un archivo).

Clave Primaria: Es aqul atributo o conjunto de atributos que identifica en forma nica
a una tupla de otra.

Clave Fornea: Es aquella clave que permite relacionar dos o ms tablas, donde en
una de las tablas debe ser necesariamente clave primaria.

SESIN # 4
2.3. SEMNTICAS DE LAS INTERRELACIONES

Existen diferentes modelos de base de datos, es decir, diferentes formas de

organizar la informacin.

Cada uno de estos modelos tiene ventajas e inconvenientes y ninguno

representa un modelo perfecto. Por ello, es fundamental realizar un estudio
previo de la informacin que se ha de manejar para poder elegir uno de los
tipos posibles como el que mejor se ajuste a los requisitos previamente indicado.

Otro factor fundamental en la eleccin del tipo de base de datos es su costo.

El costo de una base de datos se fundamenta, en gran medida, en los requisitos
necesarios para su manejo, as como en el entorno informtico en que debe
incluirse.

La base de datos jerrquica y en red, as como las documentales se instalan

generalmente, en grandes sistemas de computadores. Las razones para que
estos tipos de base de datos necesiten grandes sistemas son, en primer lugar,
su complejidad y, en segundo, est el hecho de que sus diseos originales se
realizaron, fundamentalmente, antes de la proliferacin de una
microinformtica lo suficientemente potente como para manejar enormes
volmenes de datos.

Las bases de datos relaciones, si bien se desarrollaron en su origen para

funcionar en grandes sistemas, han experimentado un considerable auge
dentro del campo de la microinformtica. Una de las razones de este auge es
que ha sido ms sencilla la creacin de sistemas gestores de bases de datos
que soporten el modelo relacional en el entorno microinformtico.
2.3.1. Nombre de la relacin

Un diagrama o modelo entidad-relacin (a veces denominado por sus siglas

en ingls, E-R "Entity relationship", o del espaol DER "Diagrama de Entidad
Relacin") es una herramienta para el modelado de datos que permite
representar las entidades relevantes de un sistema de informacin, as como
sus interrelaciones y propiedades.
2.3.2. Grado de relacin y correspondencia

Dentro del modelo entidad-relacin es importante definir estos dos conceptos

a la hora de manejar una relacin
Grado

El grado de una relacin se define como el nmero de entidades que

participan en una relacin.

Las relaciones en las que slo participan una entidad se les denomina anillo o
de grado uno; relaciona una entidad consigo misma por lo que tambin se les
llaman relaciones reflexivas.

Las relaciones que en las que participan dos entidades son binarias o de grado
dos.

Cuando en la relacin participan tres entidades sern ternarias o de grado tres.

Los conjuntos de relaciones pueden tener cualquier grado, pero lo ideal es
tener relaciones binarias.

2.3.3. Correspondencia y cardinalidad de las interrelaciones

Se define la carnalidad como el grado de participacin de las entidades en

una relacin. Para calcularlo se propone la realizacin de la siguiente pregunta:
Cuntos elementos de una entidad participarn en la relacin con un
elemento concreto de la segunda entidad? y cuntos elementos de la
segunda entidad participarn en la relacin con un elemento concreto de la
primera entidad? La respuesta ser 1 o muchos. As:
1:1 - uno a uno: Una tarjeta de embarque asigna un asiento concreto. Un
asiento es asignado por una tarjeta de embarque concreta.

1: N - uno a muchos: En una estantera concreta hay muchos libros y un libro

concreto est en una estantera.

N: M - muchos a muchos: Muchos cocineros preparan un plato concreto,

muchos platos son preparados por un cocinero concreto.
2.4. Mecanismos de abstraccin
2.4.1. Clasificacin

Generalizacin. Obtener una nueva clase de objetos a partir de sus

subclases. Utilizamos la expresin es un. Por ejemplo, la silla es un mueble.
Obtuvimos un nuevo objeto (mueble) a partir de una subclase de objetos (silla).

Especializacin. Dividir una clase general en un conjunto de subclases.

La clase mueble se puede dividir en sillas, sillones, etc.

Clasificacin. Crear o buscar clases para englobar las instancias en la

clase correspondiente. Por ejemplo, cuando a un pupitre lo clasificamos como
un mueble escolar.

Instanciacin. Obtener las instancias de una clase. Por ejemplo, tu silln

favorito es una instancia de la clase silln.

Agregacin. Considerar un objeto basndose en los elementos o

propiedades que lo constituyen. Como cuando nos dicen que un objeto tiene
4 patas (elemento), un respaldo (elemento), y es cmodo (propiedad),
concluimos que es un mueble.

Refinamiento. Representar los elementos o propiedades de una clase. Un

sof es alto, ancho y tiene tapicera.

Para modelar un objeto abstracto a partir de uno del mundo real podemos
seguir dos estrategias:
1. Ascendente. Utilizando agregacin, generalizacin y clasificacin.
1. Descendente. Utilizando especializacin, instanciacin y refinamiento.
2.4.2. Generalizacin

Es posible combinar una serie de conjuntos de entidades (subconjuntos) que

comparten alguna caracterstica en un conjunto de entidades de un nivel
superior (conjunto genrico).

Jerarqua de Generalizacin: Un conjunto de entidades E es una

generalizacin de los conjuntos E1, E2, ..., En si cada entidad de los conjuntos
E1, E2, ..., En es, tambin, una entidad de la clase E.
 Herencia de atributos: Las entidades de nivel ms bajo heredan los atributos
y la participacin en las relaciones del conjunto de entidades de ms alto nivel
con el que estn enlazadas.

La relacin que existe entre el conjunto genrico y los subconjuntos es una

relacin es un (is a).

Especializacin y generalizacin son operaciones inversas.

SESIN # 5
2.5. MODELO ENTIDAD RELACIN EXTENDIDO
El Modelo Entidad-Relacin Extendido incluye todos los conceptos del Entidad-
Relacin e incorpora los conceptos de Subclase y superclase con los
conceptos asociados de Especializacin y Generalizacin.
Subclases, Superclases y Especializacin:

En el modelo Entidad-Relacin, una entidad agrupa un conjunto de

ocurrencias de entidad del mismo tipo. En muchos casos, estas ocurrencias se
pueden agrupar a su vez en otros subconjuntos que tienen un significado propio
para los propsitos de la Base de Datos y, por tanto, deberan representarse de
forma explcita.

Una generalizacin se define como una entidad llamada superclase la cual

contiene los aspectos ms generales de una aplicacin y pueden existir tantas
superclases como se requiera. Si esas existen se les conoce tambin con el
nombre de entidades fuertes.

La especializacin se define como el conjunto de entidades que tienen

caractersticas ms particulares de la aplicacin y para estas existan deber
de ocurrir una instancia de la superclase, pero no necesariamente ocurrir
ocurrencias de las subclases (entidades dbiles).

En el modelo entidad-relacin extendido, una entidad agrupa un conjunto de

ocurrencias de entidad del mismo tipo, en muchos casos esas ocurrencias
tienen un significado propio para la base de datos y se debern de representar
de otra manera. Por ejemplo, la entidad empleado puede a su vez subdividirse
en docente y no docente y cada una de estas subdivisiones se le llamaran
subclase.
Las subclases debern de pertenecer a una superclase y podremos tener las
relaciones clase/subclase que en el ejemplo anterior las relacionemos con
empleado/docente y empleado/no docente.

Debido a que una subclase es a su vez parte de una superclase, la superclase

tendr sus atributos especficos, as como los atributos correspondientes a la
superclase a la cual pertenece. Si esto existe en un diagrama se dice entonces
que existe una herencia. De la misma manera en que se heredan los atributos,
las subclases heredarn las relaciones que contenga la superclase.

El proceso por el cual se definen las diferentes subclases de una superclase se

le conoce con el nombre de especializacin, y la forma de denotar ser la
siguiente: se pondr un circulo y dentro del circulo la letra "d", y el circulo
deber de estar entre la superclase y la subclase. Este crculo podr unir a ms
de dos subclases y la letra "d" significa desunin.

La desunin significa que cada subclase es completamente independiente de

las otras y que una instancia de la superclase podr tener solamente una
ocurrencia de una subclase.
2.5.1. Restricciones sobre interrelaciones

1. Restriccin de Clave Primaria (PRIMARY KEY), permite declarar un atributo

o conjunto de atributos como la clave primaria de una relacin.

2. Restriccin de Unicidad (UNIQUE), permite que una clave alternativa o

secundaria pueda tomar valores nicos para las tuplas de una relacin (como
si de una clave primaria se tratara). Se entiende que la clave primaria siempre
tiene esta restriccin.

3. Restriccin de Obligatoriedad (NOT NULL), permite declarar si uno o varios

atributos de una relacin debe tomar siempre un valor.

4. Restriccin de Integridad Referencial o de Clave Fornea (FOREIGN KEY),

se utiliza para que mediante claves forneas podamos enlazar relaciones de
una base de datos. La integridad referencial nos indica que si una relacin tiene
una clave fornea que referencia a otra relacin, cada valor de la clave
fornea o ajena tiene que ser igual a un valor de la clave principal de la
relacin a la que referencia, o bien, ser completamente nulo. Los atributos que
son clave fornea en una relacin no necesitan tener los mismos nombres que
los atributos de la clave primaria con la cual ellos se corresponden. El diseador
de la base de datos deber poder especificar qu operaciones han de
rechazarse y cules han de aceptarse, y en este caso, qu operaciones de
compensacin hay que realizar para mantener la integridad de la base de
datos. Para ello el diseador debe plantearse tres preguntas por cada clave
fornea:
1. Puede aceptar nulos esa clave fornea? Por ejemplo, (tomando como
referencia las relaciones PROVEEDORES, ARTICULOS) tiene sentido la existencia
de un artculo cuyo proveedor se desconoce? Evidentemente, no. En algunos
casos esta respuesta podra ser distinta, por ejemplo, en una base de datos con
las relaciones EMPLEADOS y DEPARTAMENTOS, podra existir un empleado no
asignado de momento a un departamento.

2. Qu deber suceder si se intenta eliminar una tupla referenciada por

una clave fornea? Por ejemplo, si se intenta eliminar un proveedor del cual
existe algn artculo. En general, para estos casos existen por lo menos tres
posibilidades:

Restringir: La operacin de eliminacin se restringe slo al caso en el que

no existe alguna tupla con clave fornea que la referencie, rechazndose en
caso contrario. En nuestro ejemplo, un proveedor podr ser borrado, si y slo si,
por ahora, no suministra artculos.

Propagar en cascada: La operacin de borrado se propaga en cascada

eliminando tambin todas las tuplas cuya clave fornea la referencien. En
nuestro ejemplo, se eliminara el proveedor y todas las tuplas de artculos
suministrados por l.

Anular: Se asignan nulos en la clave fornea de todas las tuplas que la

referencien y se elimina la tupla referenciada. En nuestro ejemplo, no tiene
mucho sentido, pero consistira en asignar nulos al NIF-PROV de todas las tuplas
de artculos pertenecientes al proveedor que queremos borrar, y
posteriormente borrar al proveedor.

3. Qu deber suceder si hay un intento de modificar la clave primaria de

una tupla referenciada por una clave fornea? Por ejemplo, si se intenta
modificar la clave de un proveedor del cual existe algn artculo. Se actua con
las mismas tres posibilidades que en el caso anterior:
Restringir
Propagar en cascada.
Anular

5. Restriccin de Valor por Defecto (DEFAULT), permite que cuando se

inserte una tupla o registro en una tabla, para aquellos atributos para los cuales
no se indique un valor exacto se les asigne un valor por defecto.

6. Restriccin de Verificacin o Chequeo (CHECK), en algunos casos puede

ocurrir que sea necesario especificar una condicin que deben cumplir los
valores de determinados atributos de una relacin del BD, aparte de las
restricciones vistas anteriormente.
7. Aserciones (ASSERTION): Esta restriccin generaliza a la anterior, lo forman
las aserciones en las que la condicin se establece sobre elementos de distintas
relaciones (por ello debe tener un nombre que la identifique).

8. Disparadores (TRIGGERS), a veces puede interesar espeficar una accin

distinta del rechazo cuando no se cumple una determinada restriccin
semntica. En este caso, se recurre al uso de disparadores o triggers que nos
permiten adems de indicar una condicin, especificar la accin que
queremos que se lleve a cabo si la condicin se hace verdadera. Los
disparadores pueden interpretarse como reglas del tipo evento-condicin-
accin (ECA) que pueden interpretarse como reglas que especifican que
cuando se produce un evento, si se cumple una condicin, entonces se realiza
una determinada accin.
2.5.2. Generalizacin

La generalizacin es el proceso de abstraccin inverso a la especializacin. Se

quitan las diferencias entre varios tipos de entidades y generalizamos sus
caractersticas comunes para formar una entidad superclase. Dependiendo de
si las subclases pueden aparecer en ms de una subclase podemos observar
dos tipos:
Subclases disjuntas
Subclases solapadas

La jerarqua es el proceso de subdividir una entidad en varias subentidades

relacionndolas con la entidad a la que se refieren. Puede haber dos tipos:
Total: que significa que no hay otro subtipo.
Parcial: significa que puede haber otros subtipos.
Y los dos tipos de subentidades que puede haber, se dividen en dos tambin:
Exclusiva: que significa que una subentidad no puede ser otra.
Solapada: significa que una subentidad tambin puede ser otra.

Por ejemplo, en una empresa la entidad EMPLEADO con atributos NOMBRE,

DNI, DIRECCIN, TELFONO, FECHA NACIMIENTO, SALARIO y PUESTO se divide
en:
Arquitectos con atributos COMISIONES Y NUMERO DE PROYECTOS.
Administrativos con atributos PULSACIONES Y NIVEL
Ingenieros: con atributos ESPECIALIDAD Y AOS DE EXPERIENCIA
En el esquema Entidad-Relacin quedara de la siguiente forma:
CONSIDERACIONES

Generalizacin Total: todos los elementos de un tipo pertenecen a un

subtipo, es decir, que no hay otro subtipo.

Generalizacin Parcial: significa todo lo contrario, que, si hay otros

subtipos, muchas veces no aparecen en la jerarqua, pero lo tienes que
suponer.
Generalizacin exclusiva: significa que un subtipo no puede ser otro,
simplemente puede ser el mismo sin tener otra segunda opcin.

Generalizacin solapada: un subtipo puede tener la opcin de ser otro

subtipo, es decir, que no es nico.

Por tanto: generalizaciones totales y exclusivas, totales y solapadas,

parciales y exclusivas, parciales y solapadas pueden ser las opciones que
podemos tener a la hora de hacer una jerarqua.
2.5.3. Agregacin

Una limitacin del modelo E-R es que no resulta posible expresar relaciones
entre relaciones. Para ilustrar la necesidad de tales construcciones considrese
la relacin ternaria trabaja-en, que se vio anteriormente, entre empleado,
sucursal y trabajo. Supngase ahora que se desean registrar los directores para
las tareas realizadas por un empleado en una sucursal; es decir, se desean
registrar directores por combinaciones (empleado, sucursal, trabajo). Asmase
que existe una entidad director.

Una alternativa para representar esta relacin es crear una relacin

cuaternaria dirige entre empleado, sucursal, trabajo y director (se necesita una
relacin cuaternaria; una relacin binaria entre director y empleado no
permitira representar las combinaciones [sucursal, trabajo] de un empleado
que estn dirigidas por un director). Parece que los conjuntos de relaciones
trabajan-en y dirige se pueden combinar en un nico conjunto de relaciones.
No obstante, no se deberan combinar, dado que algunas combinaciones
empleado, sucursal, trabajo puede que no tengan director.

Hay informacin redundante en la figura resultante, ya que cada combinacin

empleado, sucursal, trabajo en dirige tambin lo est en trabaja-en. Si el
director fuese un valor en lugar de una entidad director, se podra hacer que
director fuese un atributo multivariado de la relacin trabaja-en. Pero esto
implica que es ms difcil (tanto lgicamente como en coste de ejecucin)
encontrar, por ejemplo, los triples empleado-sucursal-trabajo de los que un
director es responsable. Como el director es una entidad director, se descarta
esta alternativa, en cualquier caso.

3. Sesin # 6
3.1. INTRODUCCIN
3.2. TRANSFORMACIN DE MODELO ENTIDAD RELACIN A RELACIONAL
Hasta ahora hemos estado definiendo el modelo relacional, y sus relaciones
con el modelo Entidad-Relacin. Pero cmo se convierte el modelo entidad-
relacin en el modelo relacional? Es decir, a partir de un esquema entidad-
relacin, cmo obtengo sus correspondientes tablas? Vamos a verlo con
ejemplos ilustrados.
En esta primera parte 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:
3.2.1. Cardinalidad 1: 1

Un registro de una entidad A se relaciona con solo un registro en una entidad

B. (ejemplo dos entidades, profesor y departamento, con llaves primarias,
cdigo_profesor y jefe_depto respectivamente, un profesor solo puede ser jefe
de un departamento y un departamento solo puede tener un jefe).
3.2.2. Cardinalidad 1: N

Un registro en una entidad en A se relaciona con cero o muchos registros en

una entidad B. Pero los registros de B solamente se relacionan con un registro
en A. (ejemplo: dos entidades, vendedor y ventas, con llaves primarias,
cdigo_vendedor y venta, respectivamente, un vendedor puede tener
muchas ventas, pero una venta solo puede tener un vendedor).
3.2.3. Cardinalidad N: M

Una entidad en A se puede relacionar con 0 o con muchas entidades en B y

viceversa (ejemplo asociaciones-ciudadanos, donde muchos ciudadanos
pueden pertenecer a una misma asociacin, y cada ciudadano puede
pertenecer a muchas asociaciones distintas).
SESIN # 7
3.3. Normalizacin

El proceso de normalizacin de una base de datos consiste en aplicar una serie

de reglas a las relaciones obtenidas tras el paso del modelo E-R (entidad-
relacin) al modelo relacional.
Objetivo de la normalizacin
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 bidimensional sea considerada como una relacin tiene cumplir
con algunas restricciones:
Cada columna 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.
Terminologa equivalente
relacin = tabla o archivo
tupla = registro, fila o rengln
atributo = campo o columna
base de datos = banco de datos
dependencia multivaluada = dependencia multivalor
clave = llave
clave primaria = superclave
clave ajena = clave extranjera o clave fornea

RDBMS = del ingls Relational Data Base Manager System que

significa, Sistema Gestor de Base de Datos Relacionales
3.3.1. Relaciones

Relaciones entre los Datos Antes de definir el cuarto nivel de F/N, veremos tres
tipos de relaciones entre los datos: uno-a-uno, uno-con-varios y varios-con-
varios. Mira la tabla usuarios en el Primer Nivel de F/N del ejemplo de arriba. Por
un momento imaginamos que ponemos el campo url en una tabla separada,
y cada vez que introducimos un registro en la tabla usuarios tambin
introducimos una sola fila en la tabla urls. Entonces tendramos una relacin
uno-a-uno: cada fila en la tabla usuarios tendra exactamente una fila
correspondiente en la tabla urls. Para los propsitos de nuestra aplicacin no
sera til la normalizacin. Ahora mira las tablas en el ejemplo del Segundo Nivel
de F/N. Nuestras tablas permiten a un slo usuario tener asociadas varias urls.
Esta es una relacin uno con-varios, el tipo de relacin ms comn, y hasta que
se nos present el dilema del Tercer Nivel de F/N. la nica clase de relacin que
necesitamos. La relacin varios-con-varios, sin embargo, es ligeramente ms
compleja. Observa en nuestro ejemplo del Tercer Nivel de F/N que tenemos a
un usuario relacionado con varias urls. Como dijimos, vamos a cambiar la
estructura para permitir que varios usuarios estn relacionados con varias urls y
as tendremos una relacin varios-con-varios. Veamos como quedaran
nuestras tablas antes de seguir con este planteamiento:
3.3.2. Razones para normalizar
1) Normalizar los datos para una mejor identificacin de los clientes

El primer provecho para quien elige normalizar sus datos de empresa concierne
a la identificacin de los datos personales de los clientes. El software Egon
elimina automticamente de la base de datos las entradas incorrectas,
actualiza la informacin obsoleta e integra los campos vacos con detalles
tiles. El resultado es un archivo mucho ms fiable que el anterior, capaz de
ofrecer posibilidades de marketing superiores en trminos de target,
elaboracin de ofertas a medida y distribucin de mensajes publicitarios.
2) Normalizar los datos para optimizar los recursos internos

Erasing errors in the database means optimizing your employees data

management. Couriers, managers, delivery persons, marketing managers and
internal resources will no longer have to worry about checking if the information
is correct, and they will be able to perform their jobs quicker and with greater
security.
3) Normalizar los datos para reducir la inmediatez de respuesta

Disponer de miles de nombres y dar respuestas rpidas son dos exigencias que
a menudo estn en contraste entre s. Para conciliar una y otra es importante
estar organizados, un objetivo que se logra no slo a travs de una perfecta
administracin interna, sino tambin recurriendo a herramientas informticas
de normalizacin de datos. stas garantizan en cualquier momento el acceso
a datos nicos e inequivocables con la consiguiente reduccin de la
inmediatez de respuesta.
4) Normalizar los datos para conquistar la confianza del pblico

Bases de datos con direcciones y/o datos personales normalizados permiten

ofrecer un servicio creble y puntual. Nada de retrasos, ningn intercambio de
nombres, respuestas rpidas. stos son slo algunos de los ladrillos sobre los que
se construye la confianza del pblico, tanto en el mercado real como en el
virtual del comercio electrnico o del suministro de servicios online.
5) Normalizar los datos para ofrecer ms garantas

Respecto a una empresa que no cuida sus propias bases de datos, quien opta
por la normalizacin de los datos podr ofrecer a sus clientes ms garantas,
como la entrega garantizada o que se rellene automticamente la direccin
de envo durante la fase de compra. De hecho, Egon puede integrarse en las
plataformas de comercio electrnico para agilizar las compras y evitar al
mismo tiempo errores por parte del cliente. Una garanta para el usuario, una
certeza para tu negocio
3.3.3. Formas Normales

En la teora de bases de datos relacionales, las formas normales (NF)

proporcionan los criterios para determinar el grado de vulnerabilidad de una
tabla a inconsistencias y anomalas lgicas. Cuanto ms alta sea la forma
normal aplicable a una tabla, menos vulnerable ser a inconsistencias y
anomalas. Cada tabla tiene una "forma normal ms alta" (HNF): por definicin,
una tabla siempre satisface los requisitos de su HNF y de todas las formas
normales ms bajas que su HNF; tambin por definicin, una tabla no puede
satisfacer los requisitos de ninguna forma normal ms arriba que su HNF.

Las formas normales son aplicables a tablas individuales; decir que una base
de datos entera est en la forma normal n es decir que todas sus tablas estn
en la forma normal n.

Los recin llegados al diseo de bases de datos a veces suponen que la

normalizacin procede de una manera iterativa, es decir un diseo 1NF primero
se normaliza a 2NF, entonces a 3NF, etctera. sta no es una descripcin
exacta de cmo la normalizacin trabaja tpicamente. Una tabla
sensiblemente diseada es probable que est en 3NF en la primera tentativa;
adems, si est en 3NF, tambin es extremadamente probable que tenga una
forma HNF de 5NF. Conseguir formas normales "ms altas" (sobre 3NF)
usualmente no requiere un gasto adicional de esfuerzo por parte del diseador,
porque las tablas 3NF usualmente no necesitan ninguna modificacin para
satisfacer los requisitos de estas formas normales ms altas.

Edgar F. Codd originalmente defini las tres primeras formas normales (1NF, 2NF,
y 3NF). Estas formas normales se han resumido como requiriendo que todos los
atributos no-clave sean dependientes en "la clave, la clave completa, y nada
excepto la clave". La cuarta y quinta formas normales (4NF y 5NF) se ocupan
especficamente de la representacin de las relaciones muchos a muchos y
uno muchos entre los atributos. La sexta forma normal (6NF), en pocas palabras,
se basa en el principio de que, si se tiene ms de dos claves candidatas en una
tabla, se tendrn que crear otras tablas con estas.

Por ejemplo, si tenemos "tem" con un id cdigo de producto y con los atributos
descripcin y precio que son claves candidatas se tendra que crear otras
tablas separando la tabla tem: ItemDesc {cdigo_producto*, Descripcin}
ItemPrecio {cdigo_producto*, Precio}.

Conclusiones

Despus de haber realizado esta investigacin y lo que hemos visto en cada

clase hemos aprendido mucho sobre lo que es base de datos desde su diseo
como es la creacin de tablas y todo lo que lleva cada una de ellas, sus
relaciones en s,

Por lo tanto, se sabe que conocer los procesos, de la estructura he

implementacin de una base de datos nos muestra la importancia y como
cada ente que las utiliza es dependiente de ellas.

Recomendacin

Es necesario saber todo sobre base de datos ya que es una parte muy
importante para la creacin de algn software, Conocer las especificaciones
que nos presenta cuando estructuramos las tablas de cada base de datos,
realizando nuestro trabajo ms prctico y sencillo.

Las bases de datos son una parte muy importante para lo que es el mundo
laboral ya que hoy en da son muy utilizadas por las distintas instituciones para
el almacenamiento de informacin, por eso se ha vuelto una herramienta muy
necesaria para dichas instituciones.
Web Bibliogrfica:

https://tombasededatos.wordpress.com/2010/08/28/2-1-definicion-de-un-
modelo-de-datos/
http://elies.rediris.es/elies9/4-2.htm
https://irfeyal.wordpress.com/bases-de-datos/modelamiento-de-bdd/
https://irfeyal.wordpress.com/bases-de-datos/modelamiento-de-bdd/
http://www.jgarces.info/base-de-datos-introduccion/