Abstraccin de la informacin

Abstraccin de la informacin.
Una base de datos es en esencia una coleccin de archivos relacionados
entre s, de la cual los usuarios pueden extraer informacin sin considerar las
fronteras de los archivos.
Un objetivo importante de un sistema de base de datos es proporcionar a los
usuarios una visin abstracta de los datos, es decir, el sistema esconde ciertos
detalles de cmo se almacenan y mantienen los datos. Sin embargo para que
el sistema sea manejable, los datos se deben extraer eficientemente.
Existen diferentes niveles de abstraccin para simplificar la interaccin de
los usuarios con el sistema; Interno, conceptual y externo, especficamente el
de almacenamiento fsico, el del usuario y el del programador.
Nivel fsico.
Es la representacin del nivel ms bajo de abstraccin, en ste se describe
en detalle la forma en como de almacenan los datos en los dispositivos de
almacenamiento (por ejemplo, mediante sealadores o ndices para el acceso
aleatorio a los datos).
Nivel conceptual.
El siguiente nivel ms alto de abstraccin, describe que datos son
almacenados realmente en la base de datos y las relaciones que existen entre
los mismos, describe la base de datos completa en trminos de su estructura
de diseo. El nivel conceptual de abstraccin lo usan los administradores de
bases de datos, quienes deben decidir qu informacin se va a guardar en la
base de datos.
Consta de las siguientes definiciones:
Definicin de los datos: Se describen el tipo de datos y la longitud de campo
todos los elementos direccionables en la base. Los elementos por definir
incluyen artculos elementales (atributos), totales de datos y registros
conceptuales (entidades).
Relaciones entre datos: Se definen las relaciones entre datos para enlazar
tipos de registros relacionados para el procesamiento de archivos mltiples.
En el nivel conceptual la base de datos aparece como una coleccin de
registros lgicos, sin descriptores de almacenamiento. En realidad los archivos
conceptuales no existen fsicamente. La transformacin de registros
conceptuales a registros fsicos para el almacenamiento se lleva a cabo por el
sistema y es transparente al usuario.
Nivel de visin.

1
 Nivel ms alto de abstraccin, es lo que el usuario final puede visualizar del
sistema terminado, describe slo una parte de la base de datos al usuario
acreditado para verla. El sistema puede proporcionar muchas visiones para la
misma base de datos.

La interrelacin entre estos tres niveles de abstraccin se ilustra en la siguiente

figura.

Modelos de datos

Los modelos de datos aportan la base conceptual para disear aplicaciones

que hacen un uso intensivo de datos, as como la base formal para las
herramientas y tcnicas empleadas en el desarrollo y uso de sistemas de
informacin. Con respecto al diseo de bases de datos, el modelado de datos
puede ser descrito as (Brodie 1984:20): "dados los requerimientos de
informacin y proceso de una aplicacin de uso intensivo de datos (por
ejemplo, un sistema de informacin), construir una representacin de la
aplicacin que capture las propiedades estticas y dinmicas requeridas para
dar soporte a los procesos deseados (por ejemplo, transacciones y consultas).
Adems de capturar las necesidades dadas en el momento de la etapa de
diseo, la representacin debe ser capaz de dar cabida a eventuales futuros
requerimientos".
Un modelo de datos es por tanto una coleccin de conceptos bien definidos
matemticamente que ayudan a expresar las propiedades estticas y

2
dinmicas de una aplicacin con un uso de datos intensivo. Conceptualmente,
una aplicacin puede ser caracterizada por:
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.
Reglas de integridad sobre las entidades y las operaciones (por ejemplo,
transacciones).
As, un modelo de datos se distingue de otro por el tratamiento que da a estas
tres categoras. 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. Un esquema consiste en una definicin de
todos los tipos de objetos de la aplicacin, incluyendo sus atributos, relaciones
y restricciones estticas. Correspondientemente, existir un repositorio de
informacin, la base de datos, que es una instancia del esquema. Un
determinado tipo de procesos slo necesita acceder a un subconjunto
predeterminado de entidades definidas en un esquema, por lo que este tipo de
procesos puede requerir slo un subconjunto de las propiedades estticas del
esquema general. A este subconjunto de propiedades estticas se le denomina
subesquema. Una transaccin consiste en diversas operaciones o acciones
sobre las entidades de esquema o subesquema. Una consulta se puede
expresar como una expresin lgica sobre los objetos y relaciones definidos en
el esquema; una consulta identifica un subconjunto de la base de datos. Las
herramientas que se usan para realizar las operaciones de definicin de las
propiedades estticas y dinmicas de la base de datos son los lenguajes de
definicin y manipulacin de datos (DDL, DML), junto con los lenguajes de
consulta (QL) que ya hemos mencionado.

La investigacin moderna sobre modelos de datos se ha centrado en los

aspectos lgicos de las bases de datos y sobre los conceptos, herramientas y
tcnicas para el diseo de las mismas (Brodie 1984). Aspectos relativos a la
implementacin de los modelos, tales como velocidad de ejecucin,
concurrencia, integridad fsica y arquitecturas no son factores relevantes en el
estadio de anlisis de modelos de datos. La investigacin ms temprana sobre
modelos de datos s estaba ms centrada en los aspectos de representacin
fsica. Cuando hablamos de modelos de datos clsicos, nos estamos refiriendo
a la segunda de las generaciones de modelos de datos. Brodie (1984) distingue
cuatro generaciones:
Modelos de datos primitivos (orientados al fichero).
Modelos de datos clsicos.
Modelos de datos semnticos.
Modelos de datos de propsito especfico (orientados a la aplicacin).

3
Los modelos de datos primitivos estaban absolutamente orientados al fichero:
las entidades se representan en registros (divididos en campos, que
representan sus propiedades), que se agrupan en ficheros. Las relaciones entre
entidades son nicamente aquellas que pueden ser representadas usando
directorios, por ejemplo ndices y listas invertidas. Un ejemplo de DBMS
comercial de fichero, concretamente del tipo "lista invertida", es el CA-
DATACOMB de Computer Associates International.
Los modelos de datos clsicos son tres: el jerrquico, el de red y el relacional.

Modelo Entidad-Relacin
2.2.1 Definicin

Generalmente todo modelo tiene una representacin grfica, para el

caso de datos el modelo ms popular es el modelo entidad-relacin o
digrama E/R.

Se denomina as debido a que precisamente permite representar

relaciones entre entidades (objetivo del modelado de datos).

El modelo debe estar compuesto por:

Entidades

Atributos

Relaciones

Cardinalidad

Llaves

2.2.2 Conjuntos de entidades y atributos

Entidades: todo lo que existe y es capaz de ser descrito

(sustantivo).

4
 Atributos: es una caracterstica (adjetivo) de una entidad que
puede hacer 1 de tres cosas:

o Identificar

o Relacionar

o Describir

Ejemplos de entidades con sus atributos

En el diseo se pueden considerar 3 categoras de atributos

Simples o compuestos: ya sea que el atributo sea un todo o

bien este compuesto

o Color es simple, toma valores rojo, azul, etc

o Nombre es compuesto, contiene nombre de pila, apellido

materno, apellido materno

Con valores simples o multivaluados: en base a si consisten

de un solo valor o un conjunto de valores.

o Telefono o Telfonos

Derivados: que se pueden calcular en base a otros atributos

o El promedio de prstamos se puede derivar si tenemos los

valores de cada prstamo realizado a un persona

5
NOTA: en la prctica es mejor considerar "siempre" a todos los
atributos como simples y con valores simples

2.2.3 Llaves

Super llave: conjunto de uno o ms atributos que "juntos"

identifican de manera nica a una entidad

Llave candidata: es una super llave mnima

Llave primaria: la seleccionada para identificar a los elementos de

un conjunto de entidades.

Ejemplo:

Teniendo los atributos de la entidad "persona"

Nombre Direccin Telfono CURP

o Las superllaves seran:

Nombre y Direccin

Nombre y CURP

CURP

o Las llaves candidatas seran

Nombre y Direccin

CURP

o La llave primaria sera

CURP

2.2.4 Conjuntos de relaciones

6
 Relaciones: la conexin que existe entre 2 entidades (verbo).

Relacin entre 2 entidades

Relacin entre 2 entidades incluyendo un atributo en la relacin

2.2.5 Diagrama E-R

7
 Notacin empleada para elaborar modelos E-R

2.2.5.1 Diagramas E-R de relaciones entre entidades

Diagrama E-R mostrando una relacin entre 2 entidades

8
Diagrama E-R mostrando una relacin entre 2 entidades, con atributo en
la relacin

Diagrama E-R mostrando una relacin entre una misma entidad (tiles
para elaborar jerarquas)

2.2.5.2 Categoras de atributos

Ejemplos de atributos derivados, compuestos y multivaluados

NOTA: como se mencion anteriormente NO es lo mejor el

emplear estos atributos

9
2.2.5.3 Entidades dbiles

Una entidad dbil es aquella que no posee una llave primaria

Para existir dependen de una relacin con una entidad fuerte

Pueden contener algun atributo "discriminante" que podra

considerarse como aquel que lo distingue pero no de manera
nica, de ah que no se considere como llave

Diagrama E-R mostrando una relacin entre 2 entidades, una de ellas

fuerte y otra dbil

2.2.5.4 Guas de nombramiento

Es importante mantener guas o reglas para poder tener una

documentacin uniforme y consistente de todos los datos.

Entidades: una sola palabra (en singular) y con maysculas

Atributos:

o FirstName

o first_name

o de relacion: VendorID, ProductName

Valores: definir que valores son vlidos (NULL no es un valor)

2.2.5.5 Cardinalidades

En base al nmero de instancias involucradas en cada relacin, stas

presentan un cardinalidad, que puede ser:

10
 (Muchos a
Muchos)

(Uno a
Muchos)

(Uno a Uno)

Relaciones (a)uno-muchos, (b)muchos-uno,(c) uno-uno

11
2.2.5.6 Mltiples relaciones entre 2 entidades

Es posible mantener muchas relaciones entre las mismas entidades,

inclusive con distintas cardinalidades siempre y cuando cada una
represente algo totalmente independiente de las otras. No se puede
asumir que las relaciones se complementan o ni mucho menos que
compartan atributos.

2.2.5.7 Especializacin y generalizacin

Es el principio de "herencia"

Las entidades de bajo nivel heredan todos los atributos de las entidades
de mayor nivel

Si se considera de arriba hacia abajo se considera como

especializacin

Si se considera de abajo hacia arriba se considera como

generalizacin

12
 Especializacin y generalizacin

Nota: es importante mencionar que las entidades de menor nivel no

poseen una llave primaria, nicamente la entidad de nivel superior es la
que tiene entre sus atributos dicha llave y en consecuencia la "hereda" a
las entidades especializadas.

Restricciones en las generalizaciones

De pertenencia al nivel ms bajo

Definido por condicin: alguna condicin (inclusive atributo) en

el nivel alto define si una entidad puede o no pertenercer al nivel
ms bajo.

Definido por usuario: dadas ciertas condiciones basadas en el

juicio de la experiencia se decide si se puede o no pertenecer a
dicho nivel.

De pertenencia entre entidades en el nivel bajo

Disjuntas (disjoint): una entidad no puede pertenecer a 2

conjuntos de entidades de dicho nivel

Traslape (overlapping): una entidad si puede pertenercer a 2

conjuntos de entidades

13
2.2.5.8 Principios de diseo

Fidelidad: se debe crear siempre un modelo que satisfaga las

necesidades del problema, no sirve un modelo correcto si no cumple con
la realidad que se pretende representar.

Evitar redundancia: una de las ventajas del diagrama e-r es que nos
permite distinguir de una manera fcil y visual todos los entes y sus
relaciones, de manera que es muy fcil identificar si un atributo se esta
repitiendo en varias entidades o si una relacin es innecesaria.

Simplicidad: siempre hay que procurar hacer el modelo tan simple

como sea posible (sin olvidar la fidelidad) de manera que sea fcil de
entender, fcil de extender y fcil de implementar.

Escoger los elementos correctos: es ocasiones es difcil identificar si

una relacin, elemento o atributo es correcto, para ello hay que analizar
en perspectiva el diagrama y, por ejemplo si se observa una entidad con
solo un atributo y que nicamente presenta relaciones de 1, entonces
probablemente estamos hablando de un atributo y no de una entidad.

Relaciones n-arias: An cuando se pueden presentar casos en los que

una relacin terciaria o n-aria parezca ms conveniente, es mejor
siempre pensar en trminos de relaciones binarias nicamente. En el
peor de los casos de que exista una relacin n-aria forzosa, lo que se
debe hacer es convertir esa relacion R en entidad E y corregir todas las
relaciones que tena R de manera que ahora esa nueva entidad se
relacione con todas las entidades que anteriormente esta.

Relacin Ternaria

14
Resultado de la conversin de relacin de relacin 3-aria a combinacin
de 2-arias

2.2.5.9 Otras notaciones

La notacin mostrada en las secciones anteriores es solo una de las

existentes, an cuando todas en esencia representen el mismo concepto
existen una gran variedad de simbologas y depende de cada persona el
escoger aquella que ms le convenga.

Notacin E/R (1) Ross, (2) Bachmann, (3) Martin, (4) Chen, (5) Rumbaugh

Por otro lado, Booch con su propuesta de un lenguaje de modelado

unificado "UML" (Unified Modeling Language) abarca los aspectos de
"relaciones" aplicables no solo al contexto de bases de datos sino al de
programacin y muchos otros ms.

15
 Notacin UML para modelos E-R

NORMALIZACION

Existen 3 niveles de Normalizacin que deben respetarse para poder decir que nuestra
Base de Datos, se encuentra NORMALIZADA, es decir, que cumple con los requisitos
naturales para funcionar optimamente y no perjudicar las Performance por mala
arquitectura.Estas 3 reglas de Normalizacin se las conoce como las 3
FORMAS NORMALES.

La Primera Forma Normal Esta primera Forma Normal, nos lleva a no repetir datos
en nuestras tablas. Los famosos maestro detalle, deben aplicarse a la estructura de la
tabla.Si nuestra tabla de ventas repite una y otra vez (por cada venta) , el nombre, el
domicilio y otros datos del Cliente, es que no hemos aplicado esta Normalizacin.Si
tenemos una tabla clientes, en la tabla ventas, solo deberia figurar el codigo del

16
cliente, para que el resto de los datos se puedan referenciar automaticamente sin
problemas y sin duplicar informacin.Lo mismo ocurriria en una tabla de detalle de
ventas, si por cada item vendido colocamos el detalle del producto, con su descripcin ,
medidas, etcTendriamos un desaprovechamiento de espacio y recursos muy
grande. Para ello, tendremos nuestra tabla maestra de Productos y con solo grabar el
cdigo de dicho producto en nuestra tabla de ventas, ser suficiente.

La Segunda Forma Normal (Si o si debe estar previamente aplicada la Primera

Forma Normal) La Segunda Forma Normal nos habla de que cada columna de la tabla
debe depender de la clave.Esto significa que todo un registro debe depender
nicamente de la clave principal, si tuvieramos alguna columna que se repite a lo largo
de todos los registros, dichos datos deberian atomizarse en una nueva tabla.Veamos un
ejemplo

VentaID ItemID FechaVenta ClienteVenta ProductoId Cantidad

1 1 01/12/2007 2 2334 10
1 2 01/12/2007 2 3333 2
1 3 01/12/2007 2 66643 34
1 4 01/12/2007 2 21 3
2 1 02/12/2007 5 3566 6

Ahi tenemos un claro problema !!!Acaso no se busca NO REPETIR DATOS ?Si toda una
venta tendr el mismo numero de Cliente y la misma FechaPor que no crear una
Tabla de MAESTRO DE VENTAS y que contenga esos 2 datos ?Es evidente que la
columnaClienteVenta y FechaVenta se repetirn por cada venta realizada.Es por ello
que proponemos el siguiente esquema

VentaID ItemID ProductoId Cantidad

1 1 2334 10
1 2 3333 2

17
 1 3 66643 34
1 4 21 3
2 1 3566 6
Y ahora nuestra nueva tabla maestra

VentaId FechaVenta ClienteVenta

1 01/12/2007 2
2 02/12/2007 5

Entonces, nuestra 2da Forma Normal nos habla de que cada columna de una tabla
debe depender de toda la clave y no constituir un dato unico para cada grupo de
registros.

La Tercera Forma Normal En realidad si nos guiamos en el ejemplo de esta nota, ya

no quedaria normalizacin por aplicar y podriamos decir que nuestro ejemplo cumple
con las 3 formas normales, ya que la 3ra Forma Normal nos habla de que :
1. Ninguna Columna puede depender de una columna que no tenga una clave
2. No puede haber datos derivados
En el 2do ejemplo hemos descubierto campos que dependian de la clave principal
(VentaID) y que podrian incluirse en una tabla maestra.Pero supongamos un ejemplo
donde ciertas columnas no dependen de la clave principal y si dependen de una
columna de nuestra tabla.

VentaI ItemI ProductoI Cantida Descripcion Medid Proveed

D D D d a or
1 1 3455 12 Impresora HP 122cm 1
LJ8000
1 2 2455 34 Scanner HP A3555 33cm 1
2 1 5444 21 Mouse HP Wireless 1

Esto es muy normal encontrar en bases mal normalizadas.Vemos que los campos
DESCRIPCION , MEDIDA y PROVEEDOR no dependen de VENTAID y es por ello que no
deberian estar dentro de la tabla de detalle de ventas, ya que dependen de
PRODUCTOID.Aqui no se trata ya de eliminar grupos repedidos de datos (1ra Forma

18
Normal) sino que ante la inclusion de una clave perteneciente a otra tabla, cualquier
campo que sea subordinado de dicha clave debe estar en otra tabla y no en nuestra
tabla detalle.
ConclusinFinalmente si tomamos en cuenta que una tabla de detalle de venta (item
x item) puede contener un volumen de millones de registros, al haberle aplicado las 3
formas normales nos estaremos ahorrando varios Gigabytes de tamao en dicha tabla
y por supuesto mejorado notablemente la performance.

19