Maestría en Bioinformática

Bases de Datos y Sistemas de Información

Bases de Datos

Ing. Alfonso Vicente, PMP alfonso.vicente@logos.com.uy

Agenda

• Base de datos

• DBMS

• Tipos de DBMSs

• RDBMSs

Conceptos

Historia

Motivación

Agenda

• Breve historia de la disciplina Conceptos

Historia

Motivación

Agenda

• Problemas

• Beneficios de usar un RDBMS

• Cuándo no usar un RDBMS

Conceptos

Historia

Motivación

Agenda

• Base de datos

• DBMS

• Tipos de DBMSs

• RDBMSs

Conceptos

Historia

Motivación

Conceptos

Base de datos

Un conjunto de datos relacionados entre sí y que tienen un

significado implícito.

Elmasri-Navathe

base. ~ de datos.

1. f. Inform. Conjunto de datos organizado de tal modo que

permita obtener con rapidez diversos tipos de información.

Diccionario de la Real Academia Española

Una colección de datos usualmente grande organizada

especialmente para una rápida búsqueda y recuperación

(como por una computadora)

Merriam-Webster

Conceptos

Base de datos

Guía telefónica

Fichas de biblioteca

Conceptos

DBMS

Siglas de DataBase Management System

Software especializado

en la gestión de

Bases de Datos

Diseñado para manejar

de forma eficiente grandes

volúmenes de datos

Conceptos

Tipos de DBMSs

• Orientado a archivos

Conceptos

Tipos de DBMSs

• Jerárquico

Conceptos

Tipos de DBMSs

• Jerárquico

Conceptos

Tipos de DBMSs

• De Red

Conceptos

Tipos de DBMSs

• Relacional

Conceptos

Tipos de DBMSs

• Relacional (Concepto de transacción y reglas ACID)

• Transacción: Unidad de trabajo que encapsula varias

operaciones sobre una base de datos

• Atomicity: Una transacción es atómica (todo o nada)

• Consistency: Toda transacción deja a la base en un estado

consistente (constraints)

• Isolation: Ninguna transacción intefiere con otra... aunque

hay niveles aceptables (isolation levels)

• Durability: Toda transacción exitosa persiste aún ante

caídas (no data-loss)

Conceptos

Tipos de DBMSs

• Orientado a objetos

Conceptos

Tipos de DBMSs

• Objeto/Relacional

Su existencia se justifica por

el éxito de la POO y de los

DBMSs relacionales

Los OODBMSs y ORDBMSs

no tienen demasiado éxito en

la industria, es más común el

modelo RDBMS + ORM

Conceptos

Tipos de DBMSs

• NoSQL, NoREL, NewSQL, BigData, Sistemas K-V

Memcached, MapReduce, BigTable (Google), Cassandra

(Facebook), Dynamo (Amazon), MongoDB, NuoDB, VoltDB

(Stonebraker) ...muchos más: http://nosql-database.org

Surgen por la motivación de escalar bien manejando

grandes volúmenes (petabytes) de información, utilizando

para ello clusters con muchos hosts... pero no son ACID

o The Google File System

o MapReduce: Simplified Data Processing on Large Clusters

o Bigtable: A Distributed Storage System for Structured Data

Conceptos

ACID vs BASE

• La escalabilidad de nuevas tendencias mejora la

disponibilidad y la performance, pero no es gratis:

¿podemos a perder la C y la I de ACID?

BASE es:

Basically Available

Soft-State

Eventual Consistency

Ejemplo: actualizaciones de estado en Facebook

Conceptos

Teorema CAP (Consistency - Availability - Partition tolerance)

Conceptos

Teorema CAP en la práctica

• CA (Consistency & Availability, no Partition tolerance)

• CP (Consistency & Partition tolerance, no Availability)

Son el mismo caso, cuando en un sistema CA hay un

particionamiento en la red se pierde la A, y un sistema CP

sólo pierde la A cuando hay un particionamiento en la red.

Es el caso más común, se prioriza la consistencia

• AP (Availability & Partition tolerance, no Consistency)

Se prioriza la disponibilidad, y se tolera la "consistencia

eventual": Facebook, Twitter, DNS

Conceptos

RDBMSs

• Siguen vigentes debido a:

o Su madurez y su amplia adopción en la industria

o Su posibilidad de respetar las reglas ACID (cuando

debemos priorizar la consistencia, queremos un sistema

ACID y no BASE)

o La madurez de las soluciones ORM (y a que los

OODBMSs y ORDBMSs no prendieron en la industria)

o Su soporte a nuevas necesidades (XML, datos

geográficos, alta disponibilidad)

• Esto podría cambiar en los próximos 25 años: http://cs-

www.cs.yale.edu/homes/dna/papers/vldb07hstore.pdf

Agenda

• Breve historia de la disciplina Conceptos

Historia

Motivación

Historia

Teoría, tecnología, lenguaje y disciplina han evolucionado

juntas:

• Teoría: Modelos, reglas, isolation levels

• Tecnología: Implementaciones reales, mercado,

mecanismos de locking

• Lenguaje: SQL, APIs (ODBC/JDBC/SQLJ/DBI), XQuery

• Disciplina: MER, normalización, patrones

Historia

Edgar Codd (1923 - 2003)

Es el Codd de la forma normal de Boyce-

Codd, y del Teorema de Codd ("el poder

expresivo del AR es igual al de las consultas

seguras del CR")

1970: A Relational Model of Data for Large

Shared Data Banks

1979: Extending the Database Relational Model to Capture

More Meaning

1985: Las 12 reglas de Codd

Historia

Michael Stonebraker (1943)

40 años demostrando cómo implementar

DBMSs:

• Ingres (1973)

• Postgres (1985)

• Illustra (1997, Informix, IBM)

• Mariposa / Cohera (2001, Peoplesoft,

Oracle)

• Aurora / Streambase (2003)

• C-Store / Vertica (2005)

• Morpheus / Goby (2006)

• H-Store / VoltDB (2007)

• Sci-DB (2008)

Historia

Donald Chamberlin (1944) y Raymond Boyce (1947–1974)

Lenguaje declarativo basado en álgebra / cálculo relacional

• 1974: SEQUEL: A Structured English Query Language

• 80’s: SQL es un estándar de facto

• 1986: Estándar ANSI

• 1987: Ratificado por ISO

• Compliance: ANSI/ISO SQL:92, SQL:1999, SQL:2003,

SQL:2006, SQL:2008

• Dialectos, extensiones procedurales, XQuery

Historia

Peter Chen (?)

Inicia el "modelado conceptual"

1976. The Entity-Relationship Model--

Toward a Unified View of Data

2002. Entity-Relationship Modeling--

Historical Events, Future Trends, and

Lessons Learned

Agenda

• Problemas

• Beneficios de usar un RDBMS

• Cuándo no usar un RDBMS

Conceptos

Historia

Motivación

Motivación

Problemas

Imaginemos un SI de un banco que necesita:

• Restricciones de integridad (movimientos de una cuenta)

• Consistencia de transacciones (transferencia)

• Fácil acceso a los datos (reporte de saldos)

• Seguridad en el acceso a los datos (permisos, auditoría)

• Alta disponibilidad

• Recuperabilidad

Motivación

Beneficios de usar un RDBMS

• Tipado de datos, NOT NULL, Primary Keys, Foreign Keys,

Checks

• Soporte de transacciones ACID (commit, rollback), control de

concurrencia (mecanismos de locking)

• Lenguaje SQL, APIS como ODBC y JDBC

• Mecanismo estándar de autorización

• Log transaccional: Crash Recovery, Point-In-Time Recovery

• Soluciones de alta disponibilidad (clusters, hot-standby)

Motivación

Cuándo no usar un RDBMS, respuestas clásicas:

• Inversión en hardware y software

- Hay RDBMSs gratuitos con un footprint muy bajo

• Inversión en capacitación técnica

- La alternativa no la necesita ?

• Costo de administración del DBMS

- Depende de la complejidad del desarrollo, podría

funcionar totalmente desatend

• Overhead (permisos, control de concurrencia)

- En un SI simple y monousuario puede utilizar una planilla

Motivación

Cuándo no usar un RDBMS, mejores respuestas:

• Sistema muy simple, monousuario, no mantiene datos

• Sistema documental, de expedientes: hay alternativas

especializadas

• Gran volumen de datos (petabytes) y necesidad de

performance extrema: hay alternativas especializadas

(BigData), pero aún es una opción a evaluar