base. - Pedeciba

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
Conceptos
Historia
Motivación
•
•
•
•
Base de datos
DBMS
Tipos de DBMSs
RDBMSs
Agenda
Conceptos
Historia
Motivación
• Breve historia de la disciplina
Agenda
Conceptos
Historia
Motivación
• Problemas
• Beneficios de usar un RDBMS
• Cuándo no usar un RDBMS
Agenda
Conceptos
Historia
Motivación
•
•
•
•
Base de datos
DBMS
Tipos de DBMSs
RDBMSs
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
o
o
The Google File System
MapReduce: Simplified Data Processing on Large Clusters
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://cswww.cs.yale.edu/homes/dna/papers/vldb07hstore.pdf
Agenda
Conceptos
Historia
Motivación
• Breve historia de la disciplina
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 BoyceCodd, 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
Conceptos
Historia
Motivación
• Problemas
• Beneficios de usar un RDBMS
• Cuándo no usar un RDBMS
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