POLITECNICO MARIA DE LA ALTAGRACIA,
DE VILLA DUARTE (POMAVID).-
Profesora: Flor Denise Matos Pérez
Modulo 5: Administración de Base de Datos (ABD-DBA)
Nivel: 3 Código: MF_057_3
Duración: 405 horas
Año Escolar: 2019-2020
UNIDAD 1.- ADMINISTRACIÓN DE BASES DE DATOS
Es un sistema robusto que es capaz de emplear algoritmos de almacenamiento y recuperación de
información para poder implementar un modelo de datos de manera física garantizando que todas
las transacciones que se realizan con respecto a dichos datos sean "ácidas" (Atomicity,
Consistency, Isolation, Duration).
Administrador de Base de Datos (DBA)
Es un profesional en procesamiento de datos. La tarea del DBA es crear la base de datos en sí y
poner en vigor los controles técnicos necesarios. El DBA se encarga también de garantizar el
funcionamiento adecuado del sistema y de proporcionar otros servicios de índole técnica
relacionados. El DBA cuenta por lo regular con un grupo de programadores de sistemas y otros
asistentes técnicos.
Un administrador de bases de datos (DBA) tiene la responsabilidad de mantener y operar las bases
de datos que conforman el sistema de información de una compañía.
Debido a la importancia de los datos que están a su cargo, el administrador de bases de datos debe
ser experto en TI (tecnología de la información), teniendo particular conocimiento de DBMS
(sistemas de administración de bases de datos) y el lenguaje de consulta SQL. También debe tener
conocimiento de varios tipos de lenguaje de programación para poder automatizar ciertas tareas.
Una de sus tareas es la de asegurar la integridad del
sistema de información de la compañía. Además, es
necesario que posea un buen entendimiento de
DBMS para optimizar las consultas, ajustar la
configuración de DBMS o para sincronizar en
forma precisa las herramientas de control del
acceso a las bases de datos.
Es posible que el administrador de bases de datos
tenga que brindar asistencia técnica a usuarios de
las aplicaciones cliente o equipos de desarrollo para
solucionar problemas, dar consejos o ayudar a
resolver consultas complicadas.
Al trabajar con el jefe de seguridad, el administrador de bases de datos debe crear copias de
seguridad, planes y procedimientos de restauración para preservar los datos de los cuales es
responsable.
Además de estas habilidades técnicas, el administrador de bases de datos debe poseer un buen
entendimiento de las aplicaciones de la compañía y estar dispuesto a atender las necesidades de
los usuarios cuando desarrolla o edita una base de datos. En el mejor de los casos, debe tener
experiencia en diseño de sistemas de información y modelos UML (Lenguaje unificado de
modelos).
Funciones de un DBA
Además de lo ya dicho de un DBA este proporciona asesoría a los desarrolladores, usuarios y
ejecutivos que la requieran. Esta persona o equipo de personas profesionales son responsables del
control y manejo del sistema de base de datos, tiene(n) experiencia en DBMS, diseño de bases de
datos, Sistemas Operativos, comunicación de datos, hardware y programación.
Un Administrador de Base de Datos debe tener aptitudes técnicas para el manejo del sistema en
cuestión, además, son cualidades deseables nociones de administración, manejo de personal e
incluso un cierto grado de diplomacia. La característica más importante que debe poseer es un
conocimiento profundo de las políticas y normas de la empresa, así como el criterio de la empresa
para aplicarlas en un momento dado.
Son funciones del Administrador de Bases de Datos:
1. Administrar la estructura de la Base de Datos.
2. Administrar la actividad de los datos.
3. Administrar el Sistema Manejador de Base de Datos.
4. Establecer el Diccionario de Datos.
5. Asegurar la confiabilidad de la Base de Datos.
6. Confirmar la Seguridad de la Base de Datos.
1.- ADMINISTRACIÓN DE LA ESTRUCTURA DE LA BASE DE DATOS
La administración de la estructura de la Base de Datos incluye participar en el diseño inicial de la
misma y su puesta en práctica, así como controlar, y administrar sus requerimientos, ayudando a
evaluar alternativas, incluyendo los DBMS a utilizar y ayudando en el diseño general de BD. En
los casos de grandes aplicaciones
de tipo organizacional, el DBA es
un gerente que supervisa el trabajo
del personal de diseño de la BD.
Una vez diseñada la BD, es
puesta en práctica utilizando
productos del DBMS,
procediéndose entonces a la
creación de los datos (captura
inicial). El DBA participa en el
desarrollo de procedimientos y
controles para asegurar la
calidad y la alta integridad de la
BD.
Los requerimientos de los
usuarios van modificándose,
estos encuentran nuevas formas
o métodos para lograr sus
objetivos; la tecnología de la
BD se va modificando y los fabricantes del DBMS actualizan sus productos.
Todas las modificaciones en las estructuras o procedimientos de BD requieren de una cuidadosa
administración.
2.- ADMINISTRACIÓN DE LA ACTIVIDAD DE DATOS
Aunque el DBA protege los datos, no los procesa. El DBA no
es usuario del sistema, en consecuencia, no administra valores
de datos; el DBA administra actividad de datos. Dado que la
BD es un recurso compartido, el DBA debe proporcionar
estándares, guías de acción, procedimientos de control y la
documentación necesaria para garantizar que los usuarios
trabajan en forma cooperativa y complementaria al procesar
datos en la BD.
En esta fase el DBA es responsable de:
Funciones del Administrador de Bases de Datos (DATE)
• Definir el esquema conceptual: es tarea del administrador de datos decidir con exactitud
cuál es la información que debe mantenerse en la base de datos, es decir, identificar las
entidades que interesan a la empresa y la información que debe registrarse acerca de esas
entidades. Este proceso por lo general se denomina diseño lógico –a veces conceptual-
de bases de datos. Cuando el administrador de datos decide el contenido de la base de
datos en un nivel abstracto, el DBA crea a continuación el esquema conceptual
correspondiente, empleando el DDL conceptual. El DBMS utilizará la versión objeto
(compilada) de ese esquema para responder a las solicitudes de acceso. La versión fuente
sin compilar servirá como documento de referencia para los usuarios del sistema.
• Definir el esquema interno: el DBA debe decidir también como se representará la
información en la base de datos almacenada. A este proceso suele llamársele diseño físico
de la base de datos. Una vez hecho esto el DBA deberá crear la definición de estructura
de almacenamiento correspondiente (es decir el esquema interno) valiéndose del DDL
interno. Además, deberá definir la correspondencia pertinente entre los esquemas interno
y conceptual.
En la práctica, ya sea el DDL conceptual o bien el DDL interno incluirán seguramente
los medios para definir dicha correspondencia, pero las dos funciones (crear el esquema,
definir la correspondencia) deberán poder separarse con nitidez. Al igual que el esquema
conceptual, el esquema interno y la correspondencia asociada existirán tanto en la versión
fuente como en la versión objeto.
Vincularse con los usuarios: el DBA debe encargarse de la comunicación con los usuarios,
garantizar la disponibilidad de los datos que requieren y escribir - o ayudar a los usuarios a
escribir- los esquemas externos necesarios, empleando el DDL externo aplicable. Además, será
preciso definir la correspondencia entre cualquier esquema externo y el esquema conceptual. En
la práctica, el DDL externo incluirá con toda probabilidad los medios para especificar dicha
correspondencia, pero en este caso también el esquema y la correspondencia deberán poder
separarse con claridad. Cada esquema externo y la correspondencia asociada existirán en ambas
versiones fuentes y objeto. Otros aspectos de la función de enlace con los usuarios incluyen las
consultas sobre diseño de aplicaciones, la impetración de instrucción técnica, la ayuda en la
localización y resolución de problemas, y otros servicios profesionales similares relacionados con
el sistema.
• Definir las verificaciones de seguridad e integridad: las verificaciones de seguridad y
de integridad pueden considerarse parte del esquema conceptual. El DDL conceptual
incluirá los medios para especificar dichas verificaciones.
• Definir procedimientos de respaldo y recuperación: cuando una empresa se decide a
utilizar un sistema de base de datos, se vuelve dependiente en grado sumo del
funcionamiento correcto de ese sistema. En caso de que sufra daño cualquier porción de
la base de datos – por causa de un error humano, digamos, o una falla en el equipo o en
el sistema que lo apoya – resulta esencial poder reparar los datos implicados con un
mínimo de retraso y afectando lo menos posible el resto del sistema. En teoría, por
ejemplo, la disponibilidad de los datos no dañados no debería verse afectada. El DBA
debe definir y poner en práctica un plan de recuperación adecuado que incluya, por
ejemplo, una descarga o "vaciado" periódico de la base de datos en un medio de
almacenamiento de respaldo, y procedimientos para cargar otra vez la base de datos a
partir de vaciado más reciente cuando sea necesario.
• Supervisar el desempeño y responder a cambios en los requerimientos: es
responsabilidad del DBA organizar el sistema de modo que se obtenga el desempeño que
sea "mejor para la empresa", y realizar los ajustes apropiados cuando cambien los
requerimientos.
3.- ADMINISTRACIÓN DEL DBMS
A demás de administrar la actividad de datos y la estructura de la BD, el DBA debe administrar
el DBMS mismo. Deberá compilar y analizar estadísticas relativas al rendimiento del sistema e
identificar áreas potenciales del problema. Dado que la BD está sirviendo a muchos grupos de
usuarios, el DBA requiere investigar todas las quejas sobre el tiempo de respuesta del sistema, la
precisión de los datos y la facilidad de uso. Si se requieren cambios el DBA deberá planearlos y
ponerlos en práctica.
El DBA deberá vigilar periódica y continuamente las actividades de los usuarios en la BD. Los
productos DBMS incluyen tecnologías que reúnen y publican estadísticas. Estos informes
pudieran indicar cuales fueron los usuarios activos, que archivos y que elementos de datos han
sido utilizados, e incluso el método de acceso que se ha aplicado. Pueden capturarse y reportarse
las tasas de error y los tipos de errores. El DBA analizará estos datos para determinar si se necesita
una modificación en el diseño de la BD para manejar su rendimiento o para facilitar las tareas de
los usuarios; de ser así, el DBA la llevará a cabo.
El DBA deberá analizar las estadísticas de tiempo de ejecución sobre la actividad de la BD y su
rendimiento. Cuando se identifique un problema de rendimiento, ya sea mediante una queja o un
informe, el DBA deberá determinar si resulta apropiada una modificación a la estructura de la BD
o al sistema. Casos como la adición de nuevas claves o su eliminación, nuevas relaciones entre
los datos y otras situaciones típicas deberán ser analizadas para determinar el tipo de modificación
procedente.
Cuando el fabricante del DBMS en uso anuncie una nueva versión del producto, debe realizarse
un análisis de las características que esta incorpora y sopesarlas contra las necesidades de la
comunidad de usuarios. Si se decide la adquisición del producto, los usuarios deben ser
notificados y capacitados en su uso. El DBA deberá administrar y controlar la migración tanto de
las estructuras, como de los datos y las aplicaciones.
El software de soporte y otras características de hardware pueden implicar también
modificaciones de las que el DBA es responsable ocasionalmente, estas modificaciones traen
como consecuencia cambios en la configuración o en algunos parámetros de operación del
DBMS.
Las opciones del DBMS son ajustadas al principio, es decir, en la puesta en marcha del sistema;
en este momento se conoce muy poca información sobre las características de funcionamiento y
respuesta que proporcionará a los grupos de usuarios. El análisis de la experiencia operacional y
su rendimiento en un periodo determinado de tiempo pudieran revelar que se requiere un campo.
Si el rendimiento parece aceptable, el DBA puede considerar a un modificar algunas opciones y
observar su efecto sobre el sistema, esto en búsqueda de la optimización o afinación del mismo.
4.- ESTABLECER EL DICCIONARIO DE DATOS
Cuando se definen estándares sobre la estructura de la base de datos, se deben de registrarse en
una sección del diccionario de datos a la que todos aquellos usuarios relacionados con ese tipo de
proceso pueden acceder. Este metadato debe precisar información que nos indique con claridad
el tipo de datos que serán utilizados, sus ámbitos de influencia y sus limitantes de seguridad.
5.- ASEGURAR LA CONFIABILIDAD DE LA BASE DE DATOS
Se trata de realizar un sistema de bases de datos lo suficientemente robusto para que sea capaz de
recuperarse frente a errores o usos inadecuados. Se deben utilizar gestores con las herramientas
necesarias para la reparación de los posibles errores que las bases de datos pueden sufrir, por
ejemplo, tras un corte inesperado de luz.
6.- CONFIRMAR LA SEGURIDAD DE LOS DATOS
En esta debe tomar en cuenta:
✓ Implementar las restricciones aplicables al acceso concurrente.
✓ Restringir el acceso a los procedimientos para ciertos usuarios.
✓ Restringir al acceso a los datos para ciertos usuarios procedimientos y/o datos.
✓ Evitar la coincidencia de horarios para usuarios que comparten.
✓ Las técnicas de recuperación son otra función esencial del DBA al administrar la
actividad de datos.
El DBA es el responsable de la publicación y mantenimiento de la documentación en relación con
la actividad de los datos, incluyendo los estándares de la BD, los derechos de recuperación y de
acceso a la BD, los estándares para la recuperación de caídas y el cumplimiento de las políticas
establecidas.
Esquema Conceptual
Esquema: Descripción de la estructura de los datos de interés.
Un esquema conceptual se representa mediante un modelo conceptual de datos.
Cualidades que debe poseer un modelo conceptual:
❖ Expresividad.
❖ Simplicidad.
❖ Minimalidad.
❖ Formalidad.
Además, hay que añadir aserciones que complementen el esquema.
El Modelo Entidad – Relación es el modelo conceptual más utilizado para el diseño
conceptual de bases de datos. Fue introducido por Peter Chen en 1976.
El esquema de una base
de datos (en inglés,
database schema)
describe la estructura de
una base de datos, en un
lenguaje formal
soportado por un sistema
de gestión de base de
datos (DBMS).
En una base de datos
relacional, el esquema
define sus tablas, sus
campos en cada tabla y las relaciones entre cada campo y cada tabla.
El esquema es generalmente almacenado en un diccionario de datos. Aunque generalmente el
esquema es definido en un lenguaje de base de datos, el término se usa a menudo para referirse a
una representación gráfica de la estructura de base de datos.
Una base de datos se puede ver de diferentes formas. Cada programa que accede a la base de datos
manipula sólo ciertos datos y estructuras. Así cada programa posee una visión de la base de datos.
La unión de todos los datos y sus relaciones forman el llamado esquema conceptual. Mientras
que el esquema físico representa el almacenamiento de los datos y sus formas de acceso. El DBMS
es el encargado de realizar las traducciones para pasar del esquema conceptual al físico.
Esquema Interno
Nivel interno/físico. Se refiere a la forma en la que realmente se almacena la información de la
base de datos. Los administradores (DBA) de la base de datos son los encargados de crear y
configurar la base de datos a este nivel.
Nivel Externo. Se describen varios esquemas externos o vistas de usuario. Cada
esquema externo describe la parte de la base de datos que interesa a un grupo de usuarios
determinado, y oculta a ese grupo el resto de la base de datos. En este nivel se puede
utilizar un modelo conceptual o un modelo lógico para especificar los esquemas.
La mayoría de los SGBD no distinguen del todo los tres niveles. Algunos incluyen
detalles del nivel físico en el esquema conceptual. En casi todos los SGBD que se manejan
vistas de usuario, los esquemas externos se especifican con el mismo modelo de datos
que describe la información a nivel conceptual, aunque en algunos se pueden utilizar
diferentes modelos de datos en los niveles: conceptual y externo.
Hay que destacar que los tres esquemas no son más que descripciones de los mismos
datos, pero con distintos niveles de abstracción.
Los únicos datos que existen realmente están a nivel físico, almacenados en un dispositivo
como puede ser un disco. En un SGBD basado en la arquitectura de tres niveles, cada
grupo de usuarios hace referencia exclusivamente a su propio esquema externo. Por lo
tanto, el SGBD debe transformar cualquier petición expresada en términos de un esquema
externo a una petición expresada en términos del esquema conceptual, y luego, a una
petición en el esquema interno, que se procesará sobre la base de datos almacenada.
Si la petición es de una obtención (consulta) de datos, será preciso modificar el formato
de la información extraída de la base de datos almacenada, para que coincida con la vista
externa del usuario.
El proceso de transformar peticiones y resultados de un nivel a otro se
denomina correspondencia o transformación. Estas correspondencias pueden requerir
bastante tiempo, por lo que algunos SGBD no cuentan con vistas externas.
La arquitectura de tres niveles es útil para explicar el concepto de independencia de
datos que podemos definir como la capacidad para modificar el esquema en un nivel
del sistema sin tener que modificar el esquema del nivel inmediato superior. Se pueden
definir dos tipos de independencia de datos:
• La independencia lógica es la capacidad de modificar el esquema conceptual sin
tener que alterar los esquemas externos ni los programas de aplicación. Se puede
modificar el esquema conceptual para ampliar la base de datos o para reducirla. Si, por
ejemplo, se reduce la base de datos eliminando una entidad, los esquemas externos
que no se refieran a ella no deberán verse afectados.
• La independencia física es la capacidad de modificar el esquema interno sin tener que
alterar el esquema conceptual (o los externos). Por ejemplo, puede ser necesario
reorganizar ciertos ficheros físicos con el fin de mejorar el rendimiento de las
operaciones de consulta o de actualización de datos. Dado que la independencia física
se refiere sólo a la separación entre las aplicaciones y las estructuras físicas de
almacenamiento, es más fácil de conseguir que la independencia lógica.
En los SGBD que tienen la arquitectura de varios niveles es necesario ampliar el catálogo
o diccionario, de modo que incluya información sobre cómo establecer la
correspondencia entre las peticiones de los usuarios y los datos, entre los diversos niveles.
El SGBD utiliza una serie de procedimientos adicionales para realizar estas
correspondencias haciendo referencia a la información de correspondencia que se
encuentra en el catálogo.
La independencia de datos se consigue porque al modificarse el esquema en algún nivel,
el esquema del nivel inmediato superior permanece sin cambios, sólo se modifica la
correspondencia entre los dos niveles. No es preciso modificar los programas de
aplicación que hacen referencia al esquema del nivel superior.
Por lo tanto, la arquitectura de tres niveles puede facilitar la obtención de la verdadera
independencia de datos, tanto física como lógica. Sin embargo, los dos niveles de
correspondencia implican un gasto extra durante la ejecución de una consulta o de
un programa, lo cual reduce la eficiencia del SGBD. Es por esto que muy pocos SGBD
han implementado esta arquitectura completa.
Definición de las bases de
datos de documentos
Una base de datos de documentos es
un tipo de base de datos no relacional
que ha sido diseñada para almacenar y
consultar datos como documentos de
tipo JSON. Las bases de datos de
documentos facilitan a los
desarrolladores el almacenamiento y
la consulta de datos en una base de
datos mediante el mismo formato de
modelo de documentos que emplean
en el código de aplicación.
La naturaleza flexible, semiestructurada y jerárquica de los documentos y las bases de
datos de documentos permite que evolucionen según las necesidades de las aplicaciones.
El modelo de documentos funciona bien con casos de uso como catálogos, perfiles de
usuario y sistemas de administración de contenido en los que cada documento es único y
evoluciona con el tiempo. Las bases de datos de documentos permiten una indexación
fácil, potentes consultas ad hoc y análisis de colecciones de documentos.
Casos de uso: Administración de contenido
Una base de datos de documentos es una excelente opción para aplicaciones de
administración de contenido, como blogs y plataformas de video. Con una base de datos
documental, cada entidad que rastrea la aplicación se puede almacenar como un único
documento. La base de datos de documentos es más intuitiva para que un desarrollador
actualice una aplicación a medida que evolucionan los requisitos. Además, si el modelo
de datos necesita cambiar, solo se deben actualizar los documentos afectados. No se
requiere actualización del esquema y no es necesario tiempo de inactividad de la base de
datos para realizar los cambios.
Catálogos
Las bases de datos de documentos son eficientes y efectivas para almacenar información
de catálogo. Por ejemplo, en una aplicación de e-commerce, los diferentes productos
generalmente tienen diferentes números de atributos. La administración de miles de
atributos en bases de datos relacionales no es eficiente y afecta al rendimiento de lectura.
Al utilizar una base de datos de documentos, los atributos de cada producto se pueden
describir en un solo documento para que la administración sea fácil y la velocidad de
lectura sea más rápida. Cambiar los atributos de un producto no afectará a otros.
Las bases de datos de documentos más conocidas
Amazon DocumentDB (compatible con MongoDB)
Es un servicio de base de datos de documentos rápido, escalable, de alta disponibilidad y
completamente administrado que es compatible con cargas de trabajo de MongoDB. Los
desarrolladores pueden usar en Amazon DocumentDB el mismo código de aplicación,
controladores y herramientas para ejecutar, gestionar y escalar las cargas de trabajo que
usan en MongoDB. Además, podrán disfrutar del rendimiento, escalabilidad y
disponibilidad mejorada sin tener que preocuparse de gestionar la infraestructura
subyacente.
MongoDB
Es una base de datos no relacional de código abierto que ofrece soporte para sistemas de
almacenamiento de estilo JSON orientados a documentos. Es compatible con un modelo
de datos flexible que le permite almacenar datos de cualquier estructura, y proporciona
un amplio conjunto de características, que incluyen compatibilidad total con la
indexación, la fragmentación y la replicación.
Couchbase
La plataforma de datos de clase empresarial Couchbase incluye Couchbase Server y
Couchbase Mobile, y ha sido diseñada para aprovechar toda la potencia de las
aplicaciones móviles, IoT y web. Couchbase Server es una base de datos no relacional
nativa de la nube diseñada con una arquitectura distribuida para aumentar el rendimiento,
la escalabilidad y la disponibilidad. Permite a los desarrolladores crear aplicaciones
combinando la potencia de SQL con la flexibilidad de JSON. Couchbase Mobile incluye
una base de datos incrustada totalmente integrada, que incluye características de
seguridad y sincronización automática en tiempo real con el servidor Couchbase
altamente escalable.
QUE es JSON:
Es un formato de archivo de JavaScript Object Notation (JSON) estándar de código
abierto basado en texto que se utiliza para serializar y transmitir datos estructurados entre
un servidor y una aplicación web.
El formato JSON es fácil de leer y escribir para los humanos. También es fácil para las
máquinas analizar y generar. Aunque está basado en un subconjunto del lenguaje de
programación JavaScript, es completamente independiente del lenguaje.
El formato JSON es más pequeño, más rápido y más fácil de analizar que XML. Debido
a estas propiedades, el formato JSON es el lenguaje de intercambio de datos ideal.
Los tipos de datos en el formato JSON incluyen:
• Número - Punto flotante de doble precisión en JavaScript
• Cuerda - Unicode con comillas dobles con escape de barra invertida
• Boolean - true or false
• Formación - Una secuencia ordenada de valores separados por comas encerrados
entre corchetes
• Objeto - Una colección desordenada de clave: pares de valores, con los dos
puntos ":" separando la clave y el valor. Es una lista separada por comas encerrado
entre llaves.
• nulo - valor nulo