UNIVERSIDAD ESTATAL DEL SUR DE

MANAB
Creada mediante Ley publicada en el Registro Oficial N 261 del 7 de Febrero del ao 2001
FACULTAD DE CIENCIAS TECNICAS
CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES
 NDICE

CONTENIDO
Objetivo General ........................................................................................................... 5
DESARROLLO DEL TEMA................................................................................................. 6
SESIN # 1 ....................................................................................................................... 6
DEFINICIN DE UN MODELO DE DATOS...................................................................... 6
COMPONEBTES DE MODELOS DE DATOS ................................................................... 6
Propiedades estticas ............................................................................................... 6
Propiedades dinmicas ............................................................................................. 7
TIPOS DE MODELOS DE DATOS ..................................................................................... 7
Modelo Externo ........................................................................................................... 7
Modelos Globales ....................................................................................................... 7
Modelos Internos ......................................................................................................... 7
SESIN # 2 ....................................................................................................................... 8
METODOLOGA DEL DISEO DE BASE DE DATOS ...................................................... 8
Definicin de metodologa de diseo y desarrollo de B.D.................................. 8
Diseo Conceptual .................................................................................................... 8
Diseo Lgico .............................................................................................................. 9
Diseo Fsico................................................................................................................. 9
SESIN # 3 ..................................................................................................................... 10
INTRODUCCIN DE LOS COMPONENTES ................................................................. 10
Componentes Estticos ........................................................................................... 10
Entidad ....................................................................................................................... 10
Atributo ....................................................................................................................... 10
Dominio ...................................................................................................................... 11
Relacin ..................................................................................................................... 11
SESIN # 4 ..................................................................................................................... 11
SEMNTICAS DE LAS INTERRELACIONES .................................................................... 11
Nombre de la relacin............................................................................................. 11
Grado de relacin y correspondencia ................................................................. 12
Correspondencia y cardinalidad de las interrelaciones ................................... 13
Mecanismos de abstraccin ..................................................................................... 14
Clasificacin .............................................................................................................. 14
Generalizacin .......................................................................................................... 14
SESIN # 5 ..................................................................................................................... 15
MODELO ENTIDAD RELACIN EXTENDIDO ............................................................... 15
Restricciones sobre interrelaciones ........................................................................ 16
Generalizacin .......................................................................................................... 17
Agregacin................................................................................................................ 19
Sesin # 6....................................................................................................................... 20
INTRODUCCIN ............................................................................................................ 20
TRANSFORMACIN DE MODELO ENTIDAD RELACIN A RELACIONAL ............... 20
Cardinalidad 1: 1 ...................................................................................................... 20
Cardinalidad 1: N ..................................................................................................... 20
Cardinalidad N: M .................................................................................................... 20
SESIN # 7 ..................................................................................................................... 20
NORMALIZACIN ......................................................................................................... 20
Relaciones.................................................................................................................. 21
Razones para normalizar ......................................................................................... 22
Conclusiones ................................................................................................................. 24
Recomendacin .......................................................................................................... 24
GLOSARIO ..................................................................................................................... 25
Web Bibliogrfica: ........................................................................................................ 26
 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.
 Objetivo General
Adquirir conocimientos ms avanzados del modelo de datos y su
especificacin y entorno lenguajes de definicin y manipulacin de datos,
obteniendo habilidades necesarias para el desarrollo y el diseo conceptual
de problemas del mundo real y su implementacin en un sistema de Base de
Datos.

Objetivos especficos

Comprendemos exactamente la teora de modelo de datos,

comprendiendo aquellos sistemas basados en Base de Datos y sus
lenguajes.
Seamos capaces de realizar un correcto diseo y administracin de un
sistema de Base de Datos y realizar un sistema basado en la
escalabilidad, eficiencia, efectividad y seguridad.
Podemos desenvolver correctamente en esquemas del tipo objeto-
relacional en la elaboracin de Base de Batos.
 DESARROLLO DEL TEMA

SESIN # 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.

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

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.

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

TIPOS DE MODELOS DE DATOS

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.

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.

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

METODOLOGA DEL DISEO DE BASE DE DATOS

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.

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

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.).
 SESIN # 3

INTRODUCCIN DE LOS COMPONENTES

Componentes Estticos
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

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

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

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.

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

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.
 Mecanismos de abstraccin
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.

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

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.

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

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.
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.
 Sesin # 6

INTRODUCCIN

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:

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

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

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

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

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:
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.
 GLOSARIO
Nivel lgico: definicin de las estructuras de datos que constituyen la base de
datos.

Tuplas: Es la representacin de una fila en una de las tablas que se est

almacenando datos. Y las cuales sern llamadas por los administradores de
Base de Datos en el tiempo de ejecucin de un sistema.

Usuario FINAL: es quien accesa a las bases de datos por medio de un lenguaje
de consulta o de programas de aplicacin.

Transaccin: es una secuencia de operaciones de acceso a la base de datos

que constituye una unidad lgica de ejecucin.
Ddl: Es un lenguaje de definicin de datos

Claves: Campo o grupo de campos en un registro, que se usa para identificar

a este ltimo.
Clave Primaria: Campo o grupo de campos que identifican exclusivamente un
registr.
Campo: Grupo de caracteres
Archivo: Grupo de registros relacionados

Atributos: Es una unidad bsica e indivisible de informacin acerca de una

entidad o una relacin. Por ejemplo, la entidad proveedor tendr los atributos
nombre, domicilio, poblacin.

Cardinalidad: Es simplemente la forma en que se relacionan las Entidades, o

expresa cuantas entidades se Relacionan con otras entidades.

Semntica: Es un modelo de datos conceptual que incluye la capacidad de

expresar informacin que permite el intercambio de informacin para
interpretar su significado (semntico) de las instancias, sin necesidad de
conocer el meta-modelo.
 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/data
http://www.jgarces.info/base-de-datos-introduccion/
http://www.cyta.com.ar/elearn/bd/2_presentaciones_1.htm