2. Modelado de Datos Estructurados

2.1 Definición

 

2.2 Administración de bases de datos

 

2.2.1 Roles

La información es el centro de todas las aplicaciones de hoy en día.

La administración de la información es una tarea que tiene demasiada responsabilidad ya que el éxito o fracaso depende directamente de ella.

Hablar de la administración de información es hablar de roles, algunas organizaciones (dependiendo de los recursos humanos) los dividen en:

Nota: en pequeñas organizaciones ambos roles son ejecutados por la misma persona, a la cual por lo general se le conoce como DBA.

otros roles que no están directamente relacionados con la información pero que interactúan directamente con las personas mencionadas son:

 

 

DBA vs DA

DBA vs DA vs SA

Habilidades requeridas para ser un "buen" DBA:

 

Aspectos a considerar una oferta de trabajo de DBA:

 

Y que hay acerca del salario ??

 

 

 

2.3 Modelado de Datos

2.3.1 Definición

 

2.3.2 Metas y beneficios

 

2.3.4 Tipos de modelos de datos

Basicamente son 3:

 

2.4 Modelado de Datos Conceptual y Lógico

Algunos aspectos a considerar al momento de realizar el modelado/análisis

 

2.4.1 Modelo Entidad Relación

Generalmente todo modelo tiene una representación gráfica, para el caso de datos el modelo mas popular es el modelo entidad-relación o digrama E/R.

Se denomina asi debido a que precisamente permite representar relaciones entre entidades (objetivo del modelado de datos).

La figura 2.1 muestra distintos ejemplos de notaciones, en realidad todas muy similares.

 

Figura 2.1 Notación E/R (1) Ross, (2) Bachmann, (3) Martin, (4) Chen, (5) Rumbaugh

 

También debido al aumento de popularidad y uso de UML también se puede emplear dicha notación (figura 2.3).

Figura 2.3 Notación UML

Lo importante es que en toda organización se debe establecer un estándar que deben seguir todos los modelos de la misma.

El modelo debe estar compuesto por:

 

Componentes simbólicos


Atributos: Nombre, Edad, Semestre, Id.

Entidades: Alumno, Salón, Profesor.

Entidades Débiles: No tienen llaves primarias.

Generalización: Agrupa propiedades en común a diferentes objetos.

Relación

Cardinalidad

Figura 2.4 Componentes simbólicos E/R

Guías de nombramiento

Es importante mantener guías o reglas para poder tener una documentación uniforme y consistente de todos los datos.

Relaciones de Cardinalidad

 

(Muchos a Muchos)

(Uno a Muchos)

(Uno a Uno)

Figura 2.5 Relaciones Modelo E/R

Ejemplo Modelo E-R

Figura 2.5 Ejemplo Modelo E/R

Figura 2.5 Modelo E/R en E/R

Generalización

 

Figura 2.7 Generalización

2.4.2 Conversión a tablas (esquema de datos)

El modelo es una representación visual que gráficamente nos da una perspectiva de como se encuentran los datos involucrados en un proyecto u organización.

Pero el modelo no nos presenta propiamente una instancia de los datos, un ejemplo que muestre con claridad algunas datos de muestra y como se relacionan en realidad. Por eso es conveniente crear un "esquema", el cual consiste de tablas las cuales en sus renglones (tuplas) contienen instancias de los datos.

Las tablas 2.1 y 2.3 muestran las reglas que se deben seguir para poder crear dicho esquema.

 

modelo e-r conversión a tablas

  • una tabla por cada conjunto de entidades
    • nombre de tabla = nombre de conjunto de entidades
  • una tabla por cada conjunto de relaciones m-m
    • nombre de tabla = nombre de conjunto de relaciones
  • definición de columnas para cada tabla
    • conjuntos fuertes de entidades
      • columnas = nombre de atributos
    • conjuntos débiles de entidades
      • columnas = llave_primaria (dominante) U atributos(subordinado)
    • conjunto de relaciones R (m-m) entre A, B
      • columnas (R) = llave_primaria (A) U llave_primaria (B) U atributos(R)
    • conjunto de relaciones R (1-1) entre A y B
      • columnas (A) = atribs(A) U llave primaria(B) U atributos(R)
    • conjunto de relaciones R (1-m) entre A y B
      • columnas (B) = atribs(B) U llave primaria(A) U atributos(R)

 

Tabla 2.1

 

Para el ejemplo de la Figura 2.5 tendríamos:

escuela

id_escuela url nombre

departamento

clave_depto url nombre id_escuela

curso

clave_curso seccion nombre clave_depto

profesor

id_prof nombre extension

estudiante

id_estud nombre carrera

profesor_curso

id_prof clave_curso

estudiante_curso

id_estud clave_curso

 

modelo e-r
de generalización a tablas
dos posibilidades:

  • crear una tabla para el conjunto de entidades A de mayor nivel
    • columnas (A) = atributos(A)
  • para cada conjunto de entidades B de menor nivel, crear una tabla tal que columnas
    • (B) = atributos (B) U llave_primaria (A)

     


  • si A es un conjunto de entidades de mayor nivel para cada conjunto de entidades B de menor nivel, crear una tabla tal que:
    columnas (B) = atributos (B) U atributos (A)

 

Tabla 2.3

 

2.4.3 Normalización

Una vez creadas las tablas hay que verificar si aún se puede reducir u optimizar de alguna manera.

2.4.3.1 Dependencias funcionales

Es identificar aquellos atributos que dependen de otros y que generalizan el concepto de super-llave

Ejemplo:

ID ---> Nombre

ID --> Puesto --> Sueldo

 

2.4.3.2 Primera forma normal

Una tabla se encuentra en 1a NF, si todos sus atributos son atómicos (indivisibles)

El ejemplo clásico:

nombre dirección teléfono

En 1a. NF

nombre apellido_paterno apellido_materno dirección teléfono

 

 

2.4.3.3 Segunda forma normal

Una tabla se encuentra en 2a NF, si está en 1a NF y cada atributo que NO es llave es "completamente" dependiente de la llave.

Si tenemos la tabla:

calificaciones_cursos

id_estudiante depto clave_curso descripción calificación

 

NO se encuentra en 2a NF

{ id,clave,depto} --> descripción

{clave,depto} --> descripción

Normalizando quedaría

curso

depto clave_curso descripción

estud_curso

id depto clave_curso calificación

2.4.3.4 Tercera forma normal

Un esquema relacional se encuentra en 3NF si para toda dependencia funcional X --> A:

o

o

 

deptos

nombre_depto extensión id_jefe

empleados

id_empleado nombre_depto id_jefe

donde es evidente que nombre_depto --> id_jefe, quedaría entonces:

deptos

nombre_depto extensión id_jefe

empleados

id_empleado nombre_depto

 

2.5 Modelado Físico

El paso de un modelo lógico a uno físico requiere un profundo entendimiento del manejador de bases de datos que se desea emplear, incluyendo características como:

Como se comentó en el modelado lógico el paso de convertir el modelo a tablas hace que las entidades pase a ser tablas (más las derivadas de las relaciones) y los atributos se convierten en las columnas de dichas tablas.

Físicamente esta metáfora de una tabla se mapea al medio físico, con algunas consideraciones como se menciona en las siguientes secciones.

2.5.1 Atributos

 

2.5.1.1 Tipos de Datos

Revisar los tipos de datos disponibles en el DBMS, en especial

 

2.5.1.2 Llaves primarias

En ocasiones se pueden presentar casos en donde la llave primaria no puede representarse en alguno de los tipos ofrecidos por el dbms, en ese caso se podria definir alguno y bien optar por otra llave primaria.

Importante:

Algunos dbms poseen la capacidad de "autoincrement" o "identity property" con la cual pueden automáticamentemanipular algun atributo para generar llaves incrementales. Pero es importante verificar: como se manejan internamente ?, se pueden reiniciar ?, se permite especificar algun valor inicial ?.

 

2.5.1.3 Orden de las atributos (columnas)

Algo importante dependiendo del dbms que se utilice pero por lo general la secuencia es:

 

2.5.1.4 Integridad Referencial

 

2.5.2 Indices

"Es una tabla que contiene una lista de elementos (llaves) y números de referencia donde dichos elementos se encuentran (campos de referencia)".

Un índice es un atajo desde un campo llave hacia la localización real de los datos.

Es el punto clave de la optimización de velocidad de toda base de datos.

Si se busca alguna tupla en base a un atributo que no tiene un índice entonces se realiza un escaneo de la tabla completa lo cual es demasiado costoso, por eso es recomendable usar índices en:

No olvidar que el uso de un índice implica:

Tipos de índices:

Btrees

 

Bitmaps

Male 1000011101

Female 0110000010

Unknown 0001100000

 

Reverse Key

Basado en btrees pero usando el campo en orden inverso

Craig --> giarC

 

Partitioned

 

Btrees separados en diferentes "chunks" que inclusive pueden ser distintas particiones del disco

Ordered

Especificacion del btree para indicar si ordena ascendente o descendentemente

 

otros serían:

 

Hashing

Acceso directo a los datos a través de una fórmula de hash. El inconveniente es que requiere de espacio adicional en disco y no es útil al recuperar "rangos" de datos.

 

Clustering

La idea es mantener las tuplas ordenadas bajo algún criterio. El inconveniente es que requiere de espacio adicional, cuando se acaba entonces se puede seguir insertando pero se pierde el concepto de clustering.

 

Interleaving Data

Cuando 2 tablas de antemano se sabe que se mezclarán (join) para buscar cierta información entonces es conveniente hacer esa mezcla en el disco. La mayoría de los dbms no lo hacen de manera directa, se prefiere el clustering.

 

 

 

2.5.3 Structured Query Language (SQL)

CREATE

create table table_name (

column_name column_type column_modifiers,

...,

column_name column_type column_modifiers);

 

create table musicians(

musician_id INT,

last_name CHAR(40),

first_name CHAR(40),

nickname CHAR(40));

 

 

 

INSERT

insert into table_name (column_name, ..., column_name)

values (value, ..., value);

 

insert into musicians (musician_id, last_name, first_name, nickname)

values(2,'Lydon','John','Johnny Rotten');

 

 

UPDATE

update table_name

set column_name= value,

...,

column_name=value

where column_name=value;

 

update albums

set year=1994

where album_id=4;

 

update albums

set category='old music'

where year < 1980;

 

 

DELETE

delete from table_name

where column_name=value

 

delete from albums

where albums_id=4;

 

 

SELECT

select column_name, ..., column_name

from table_name

where column_name=value;

 

select title

from albums

where category='industrial';

 

 

JOIN

select bands.band_name

from bands,albums

where albums.category='alternative'

and bands.band_id=albums.band_id;

 

 

SUBQUERIES

select title

from albums,

where band_id in

(select bands.band_id

from bands, band_musician

where band_musician.musician_id=2

and bands.band_id=band_musician.band_id);

 

 

2.6 Bases de datos temporales

2.6.1 Temporalidad

2.6.2 Caso práctico

2.6.2.1 Problema inicial

Si una empresa desea tener almacenada la información de sus proveedores, puede tener un esquema como:

Esquema

Supplier(ID, Name)
Sell (ID_Supplier, ID_Product)
Product(ID, Name, Description)


Restricciones de integridad

de manera que una consulta como el encontrar el nombre del vendedor o los productos que vende puede ser algo muy fácil de hacer en SQL:

SELECT Name
FROM Supplier, Sell
WHERE Supplier.ID=Sell.ID_Supplier and Supplier.name='Samsung'

 

Otras consultas:

  1. Obtener los proveedores que son capaces de ofrecer al menos 1 producto.
  2. Obtener los proveedores que no pueden ofrecer ningún producto.

 

2.6.2.3 Problema de antigüedad

Sin embargo si la compañía desea mantener un histórico de los distintos productos ofrecidos por cada proveedor a lo largo de la historia, entonces el problema se complica y habria que modificar el esquema a algo como:

Supplier(ID, Name, Since date)

Sell (ID_Supplier, ID_Product, Since date)

 

Qué restricciones de integridad se presentan ??

 

Consultas:

  1. Obtener los proveedores que son capaces de ofrecer al menos 1 producto y para cada uno de los productos obtener la fecha desde la cual lo hace.
  2. Obtener los proveedores que no pueden ofrecer ningún producto y desde cuándo no pueden hacerlo.

 

2.6.2.4 La solución real

Supplier(ID, Name, From date, To date)

Sell (ID_Supplier, ID_Product, From date, To date)

Nota: Algunos DBMS ofrecen la opción de incluir "intervalos (Intervals) como un tipo de dato.

 

Qué se está asumiendo ?

 

Qué restricciones de integridad se presentan ??

 

2.6.3 Conclusiones