El administrador de base de datos (DBA) es el tcnico responsable de implementar las decisiones del administrador de datos.

Por lo tanto, debe ser un profesional en IT. El trabajo del DBA consiste en crear la base de datos real e implementar los controles tcnicos necesarios para hacer cumplir las diversas decisiones de las polticas hechas por el DA. El DBA tambin es responsable de asegurar que el sistema opere con el rendimiento adecuado y de proporcionar una variedad de otros servicios tcnicos. El administrador de bases de datos (DBA1 ) es el profesional de tecnologas de la informacin y la comunicacin responsable de los aspectos tcnicos, tecnolgicos, cientficos, inteligencia de negocios y legales de bases de datos. Los administradores de bases de datos, implementan, dan soporte y gestionan, bases de datos corporativas. Los administradores de bases de datos, crean y configuran bases de datos relacionales. Los administradores de bases de datos, son responsables de la integridad de los datos y la disponibilidad. Los administradores de bases de datos, disean, despliegan y monitorizan servidores de bases de datos. Los administradores de bases de datos, disean la distribucin de los datos y las soluciones de almacenamiento. Los DBAs, garantizan la seguridad de las bases de datos, incluyendo backups y recuperacin de desastres. Los administradores de bases de datos, planean e implementan el aprovisionamiento de los datos y aplicaciones. Los administradores de bases de datos, transfieren la informacin de las bases de datos a dispositivos mviles integrados. Los administradores de bases de datos seniors, disean y crean las bases de datos corporativas. Los DBAs, analizan y reportan datos corporativos que ayuden a conformar decisiones de negocio. Los DBAs, producen diagramas de entidades relacionales y diagramas de flujos de datos, normalizacin esquemtica, localizacin lgica y fsica de bases de datos y parmetros de tablas. Los administradores de bases de datos tienen competencias y capacidades en uno o ms sistemas de gestin de bases de datos, algunos ejemplos: Microsoft SQL Server, IBM DB2, Oracle MySQL y bases de datos Oracle. En ingeniera estadstica es una de las cualificaciones subyacentes, que trata la informacin para almacenarla, hacerla altamente explotable y altamente disponible. Adems, vela por la eficacia tcnolgica del almacenamiento en el desempeo de investigaciones, buscando inferencias slidas y compactas, para canalizar resultados manteniendo un equilibrio entre las ciencias involucradas y la propiamente enunciada, ingeniera estadstica de las ciencias de la computacin. El control de tecnologas de bases de datos y las matemticas permite al DBA rendir informes, realizar reportes sobre cualquier proceso industrial y participar de forma activa en procesos avanzados de desarrollo, consolidando las capacidades propias de un profesional de tecnologas de la informacin y un ingeniero especialista. Los factores de xito en la carrera del DBA se versan sobre las cualificaciones en los avances de las tecnologas de gestin del almacenamiento, los avances en sistemas gestores de bases de datos y requerimientos de cualificacin para cada proyecto como garanta de calidad necesaria en el rol a asignar, incluyendo, tcnicas avanzadas de gestin de infraestructuras tecnolgicas, la gestin de protocolos y servicios de redes, la optimizacin de cdigo de programacin, garantizar el procesamiento eficaz de informacin, la gestin de interfaces integrales para el tratamiento de datos, la gestin de cambios, la gestin por objetivos y las gestin por resultados. Administracin de datos y administracin de bases de datos La informacin es uno los activos ms valiosos de la empresa, es indispensable contar con una persona -el administrador de datos- que conozca la informacin, y las necesidades de la empresa en este aspecto, en un nivel gerencial superior. As la labor del administradorde datos es decidir en primer trmino cules datos deben almacenarse en la base de datos, y establecer polticas para mantener y manejar los datos uan vez almacenados. El administrador de datos es por lo general, un gerente, no un tcnico. El tcnico responsable de poner en prctica las decisiones del administrador de datos es el administrador de bases de datos(DBA, database administrator).

El alcance de la actividad de la Administracin de Datos es la organizacin completa (empresa, institucin u otro organismo), mientras que el alcance de la Administracin de Bases de Datos queda restringido a una Base de Datos en particular y a los sistemas que los procesan. La Administracin de la Base de Datos opera dentro de un marco proporcionado por la Administracin de Datos facilitndose de esta manera el desarrollo y el uso de una Base de Datos y sus aplicaciones. Las siglas DBA suelen utilizarse para designar tanto la funcin Administracin de Base de Datos como al titulo del puesto administrador de Base de Datos. En los distintos niveles y aplicaciones de Base de Datos existe la funcin DBA, aunque varia en complejidad. Esta es ms sencilla cuando se trata de una Base de Datos Personal que cuando se refiere a una Base de Datos de grupos de trabajo, y esta a su vez es ms sencilla que en una Base de Datos Organizacional. En una Base de Datos Personal comnmente el mismo usuario es el Administrador de la Base de Datos; las Bases de Datos de grupos de trabajo requieren de una o dos personas que normalmente no se dedican a esta funcin de tiempo completo puesto que tienen otras responsabilidades dentro o fuera de la organizacin. En las Bases de Datos Organizacionales, que comnmente permiten el acceso a decenas e incluso centenas de usuarios, se requiere de un administrador de Base de Datos de tiempo completo; lo anterior debido al alto volumen de procesos que deben desarrollarse, controlarse y supervisarse. Un Administrador de Base de Datos de tiempo completo normalmente tiene aptitudes tcnicas para el manejo del sistema en cuestin a dems, son cualidades deseables nociones de administracin, manejo de personal e incluso un cierto grado de diplomacia. La caracterstica ms importante que debe poseer es un conocimiento profundo de las polticas y normas de la empresa as como el criterio de la empresa para aplicarlas en un momento dado. Funciones del DBA As, el DBA, a diferencia del administrador de datos, 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 tcnicos necesarios para apoyar las polticas dictadas por el administrador de datos. El DBA se encarga tambin de garantizar el funcionamiento adecuado del sistema y de proporcionar otros servicios de ndole tcnica relacionados. El DBA cuenta por lo regular con un grupo de programadores de sistemas y otros asistentes tcnicos. La responsabilidad general del DBA es facilitar el desarrollo y el uso de la Base de Datos dentro de las guas de accin definidas por la administracin de los datos. El DBA es responsable primordialmente de: Administrar la estructura de la Base de Datos Administrar la actividad de los datos Administrar el Sistema Manejador de Base de Datos Establecer el Diccionario de Datos Asegurar la confiabilidad de la Base de Datos Confirmar la seguridad de la Base de Datos Administracin de la estructura de la Base de Datos

La administracin de la estructura de la Base de Datos incluye participar en el diseo inicial de la misma y su puesta en practica as como controlar, y administrar sus requerimientos, ayudando a evaluar alternativas, incluyendo los DBMS a utilizar y ayudando en el diseo general de BD. En los casos de grandes aplicaciones de tipo organizacional, el DBA es un gerente que supervisa el trabajo del personal de diseo de la BD. Una vez diseada la BD, es puesta en practica utilizando productos del DBMS, procedindose entonces a la creacin 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 modificndose, estos encuentran nuevas formas o mtodos para lograr sus objetivos; la tecnologa 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 administracin. Implicaciones por la modificacin de los esquemas Las solicitudes de modificacin son inevitables una vez que el sistema ha entrado en operacin, pueden aparecer solicitudes de nuevos requerimientos o estos pueden resultar de una comprensin inadecuada de los mismos. En cualquier caso, debern efectuarse modificaciones en relacin con toda la comunidad de la BD, ya que el impacto de tales alteraciones ser resentido por mas de una aplicacin. En algunos casos, pueden darse modificaciones que presentan efectos negativos para algunos usuarios; estos casos debern ser tratados esgrimiendo como argumento los beneficios globales que sern obtenidos de tales alteraciones. Una administracin eficaz de la BD debe incluir procedimientos y polticas mediante las cuales los usuarios puedan registrar sus necesidades de modificaciones, y as la comunidad podr analizar y discutir los impactos de dichas modificaciones, determinndose entonces la puesta o no en practica de tales alteraciones. En razn del tamao y complejidad de una BD y de sus aplicaciones, las modificaciones pudieran tener resultados inesperados. El DBA debe estar preparado para reparar la BD y reunir suficiente informacin para diagnosticar y corregir el problema provocado por la falla. Despus de un cambio la BD es ms vulnerable a fallas. Documentacin La responsabilidad final de un DBA en la administracin de la estructura de una BD es la DOCUMENTACIN. Es de suma importancia saber que modificaciones han sido efectuadas, como fueron realizada y cuando fueron establecidas. Una modificacin sobre la estructura de la BD pudiera ocasionar un error que no apareciera a corto plazo; una vez que este surja, sin la documentacin adecuada sobre las modificaciones realizadas, l diagnostico resultara extremadamente complicado. En estos casos, se hara necesario una secuencia de rejecuciones para intentar detectar el punto en conflicto; el riesgo de este procedimiento radica en que es posible afectar la informacin contenida en la BD. Para identificar un cambio es de suma importancia mantener un registro de los formatos de prueba y de las ejecuciones de las pruebas efectuadas. Si se utilizan procedimientos de prueba formatos de pruebas y mtodos de registro estandarizados, el registro de los resultados de la prueba no consumir tiempo excesivo. Comnmente el tiempo de la documentacin es tedioso y esto ocasiona que algunos DBA tienden a reducir o abreviar la informacin que se registra en ella e incluso llegan a desatenderla. Cuando ocurre un siniestro, la documentacin completa y organizada puede ser la diferencia entre resolver o

no un problema de extrema importancia y en la mayora de los casos, que implica costos cuantiosos a la empresa. La tarea de la documentacin es cada vez ms ligera y precisa cuando se utilizan DBMS que integran herramientas CASE para las tareas de diseo, mantenimiento y documentacin. Estas mismas herramientas CASE proporcionan en la, mayora de los casos la facilidad de generar y mantener en forma automtica el Diccionario de Datos. Una razn ms para documentar consiste en la necesidad de mantener organizados datos histricos. Ocurre comnmente que se desea realizar una consulta sobre los respaldos para conocer el estado que guardaba la informacin en un periodo determinado que transcurri previamente. Los registros de modificacin existentes en la documentacin permitir resolver problemas de incompatibilidad entre las estructuras que eran vigentes en el periodo de respaldo y las que lo son ahora; permitir tambin el desarrollo de mdulos de ajuste que faciliten la traduccin de formatos y/o escalas para valores almacenados. En los casos de cadas del sistema se presenta una situacin parecida; los respaldos son requeridos y habr de verificarse su estructura; formato y escala para integrarlos a la operacin del sistema. Administracin 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 estndares, guas de accin, procedimientos de control y la documentacin necesaria para garantizar que los usuarios trabajan en forma cooperativa y complementaria al procesar datos en la BD. Como es de suponerse, existe una gran actividad al interior de un DBMS. La concurrencia de mltiples usuarios requieren de estandarizar los procesos de operacin; el DBA es responsable de tales especificaciones y de asegurarse que estas lleguen a quienes concierne. Todo el mbito de la BD se rige por estndares, desde la forma como se capture la informacin (tipo, longitud, formato), como es procesada y presentada. El nivel de estandarizacin alcanza hasta los aspectos ms internos de la BD; como s accesa a un archivo, como se determinan los ndices primarios y auxiliares, la foliacin de los registros y dems. Debe procurarse siempre que los estndares que sern aplicados beneficien tambin a los usuarios, privilegiando siempre la optimizacin en la operacin del DBMS y el apego de las polticas de la empresa. Una administracin de BD efectiva deber disponer siempre de este tipo de estndares; entre las funciones del DBA se encuentra la de revisarlos peridicamente para determinar su operatividad, y en su caso ajustarlos, ampliarlos o cancelarlos. Es tambin su responsabilidad el que estos se cumplan. Cuando se definen estndares sobre la estructura de la BD, estos deben registrarse en una seccin del diccionario de datos a la que todos aquellos usuarios relacionados con ese tipo de proceso pueden acceder. Otro de los aspectos que el administrador debe atender es el de coordinar las nuevas propuestas para realizar ajustes en los derechos de acceso a datos compartidos y aplicaciones especficamente propuestas seran analizados en conjunto con los supervisores o directivos de las reas involucradas para determinar si procede pudieran aparecer problemas cuando dos o ms grupos de usuarios quedan autorizados para notificar los mismos datos. Uno de tales conflictos es el de la actualizacin

perdida; este ocurre cuando el trabajo de un usuario queda sobrescrito sobre por el de un segundo usuario. El DBA queda responsabilizado para identificar la posible ocurrencia de dichos problemas as como de crear normas y procedimientos para su eliminacin. Se obtendrn este tipo de garantas cuando el DBMS sea capaz de implementar las restricciones aplicables al acceso concurrente, y este sea utilizado adecuadamente por programadores y usuarios; para borrar lo anterior, se hace indispensable el apego a los estndares el seguimiento de instructivos y manuales y las reglas establecidas para los diversos procesamientos y procedimientos que se llevan acabo. Entre las alternativas mas utilizadas por el DBA para tratar de resolver o minimizar este problema se encuentran las siguientes: a) Restringir el acceso a los procedimientos para ciertos usuarios. b) Restringir al acceso a los datos para ciertos usuarios procedimientos y/o datos. c) Evitar la coincidencia de horarios para usuarios que comparten. Las tcnicas de recuperacin son otra funcin esencial del DBA al administrar la actividad de datos. A pesar de que el DBMS lleva a cabo una parte del proceso de recuperacin, los usuarios determinan en forma critica la operatividad de esos sistemas de proteccin. El DBA debe anticipar fallas y definir procedimientos estndares de operacin; los usuarios deben saber que hacer cuando el sistema este cado y que es lo primero que debe realizarse cuando el sistema este puesto en marcha nuevamente. El personal de operacin deber saber como iniciar el proceso de recuperacin de la BD que copias de seguridad utilizar; como programar la rejecucin del tiempo perdido y de las tareas pendientes; es importante tambin establecer un calendario para llevar a cabo estas actividades sin afectar a otros sistemas dentro de la organizacin que hagan uso de los mismos recursos de computo. Destacan por su importancia en el proceso de recuperacin y a su vez en la atencin que prestan a otros sectores de la organizacin. Los dispositivos de comunicacin remota, los sistemas de interconexin y otros accesorios de uso compartido. El DBA es el responsable de la publicacin y mantenimiento de la documentacin en relacin con la actividad de los datos, incluyendo los estndares de la BD, los derechos de recuperacin y de acceso a la BD, los estndares para la recuperacin de cadas y el cumplimiento de las polticas establecidas. Los productos DBMS ms populares que se encuentran en el mercado proporcionan servicios de utilerias para ayudar al DBA en la administracin de los datos y su actividad. Algunos sistemas registran en forma automtica los nombres de los usuarios y de las aplicaciones a las que tienen acceso as como a otros objetos de la BD. Incorpora tambin utilerias que permitan definir en el diccionario de datos las restricciones para que determinadas aplicaciones o mdulos de ellas solo tengan acceso a segmentos especficos de la BD. Funciones del Administrador de Bases de Datos (DATE) Definir el esquema conceptual: es tarea del administrador de datos decidir con exactitud cual es la informacin que debe mantenerse en la base de datos, es decir, identificar las entidades que interesan a la empresa y la informacin que debe registrarse acerca de esas entidades. Este proceso por lo general se denomina diseo lgico 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 continuacin el esquema conceptual correspondiente, empleando el DDL conceptual. El DBMS utilizar la versin objeto (compilada) de ese esquema para responder a las solicitudes de acceso. La versin fuente sin compilar servir como documento de referencia para los usuarios del sistema.

Definir el esquema interno: el DBA debe decidir tambin como se representar la informacin en la base de datos almacenada. A este proceso suele llamrsele diseo fsico de la base de datos. Una vez hecho esto el DBA deber crear la definicin de estructura de almacenamiento correspondiente (es decir el esquema interno) valindose del DDL interno. Adems deber definir la correspondencia pertinente entre los esquemas interno y conceptual. En la prctica, ya sea el DDL conceptual o bien el DDL interno incluirn seguramente los medios para definir dicha correspondencia, pero las dos funciones (crear el esquema, definir la correspondencia) debern poder separarse con nitidez. Al igual que el esquema conceptual, el esquema interno y la correspondencia asociada existirn tanto en la versin fuente como en la versin objeto. Vincularse con los usuarios: el DBA debe encargarse de la comunicacin con los usuarios, garantizar la disponibilidad de los datos que requieren y escribir - o ayudar a los usuarios a escribirlos esquemas externos necesarios, empleando el DDL externo aplicable. Adems, ser preciso definir la correspondencia entre cualquier esquema externo y el esquema conceptual. En la prctica, el DDL externo incluir con toda probabilidad los medios para especificar dicha correspondencia, pero en este caso tambin el esquema y la correspondencia debern poder separarse con claridad. Cada esquema externo y la correspondencia asociada existirn en ambas versiones fuentes y objeto. Otros aspectos de la funcin de enlace con los usuarios incluyen las consultas sobre diseo de aplicaciones, la impetracin de instruccin tcnica, la ayuda en la localizacin y resolucin 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 recuperacin : 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 dao cualquier porcin 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 mnimo de retraso y afectando lo menos posible el resto del sistema. En teora, por ejemplo la disponibilidad de los datos no daados no debera verse afectada. El DBA debe definir y poner en prctica un plan de recuperacin adecuado que incluya, por ejemplo una descarga o "vaciado" peridico 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 ms reciente cuando sea necesario. Supervisar el desempeo y responder a cambios en los requerimientos : es responsabilidad del DBA organizar el sistema de modo que se obtenga el desempeo que sea "mejor para la empresa", y realizar los ajustes apropiados cuando cambien los requerimientos. Funciones del Administrador de Bases de Datos (KORTH) Definicin del esquema: el esquema original de la base de datos se crea escribiendo un conjunto de definiciones que son traducidas por el compilador de DDL a un conjunto de tablas que son almacenadas permanentemente en el DICCIONARIO DE DATOS. Definicin de la estructura de almacenamiento y del mtodo de acceso : estructuras de almacenamiento y mtodos de acceso adecuados se crean escribiendo un conjunto de definiciones que son traducidas por el compilador del lenguaje de almacenamiento y definicin de datos. Modificacin del esquema y de la organizacin fsica : las modificaciones, tanto al esquema de la base de datos como a la descripcin de la organizacin fsica de almacenamiento, aunque relativamente poco comunes, se logran escribiendo un conjunto de definiciones que son usadas bien

por el compilador del DDL o bien por el compilador del lenguaje de almacenamiento y definicin de datos para generar modificaciones a las tablas internas apropiadas del sistema (por ejemplo, el diccionario de datos). Concesin de autorizacin para el acceso a los datos : la concesin de diferentes tipos de autorizacin permite al administrador de la base de datos regular qu partes de la base de datos van a poder ser accedidas por varios usuarios. Especificacin de las restricciones de integridad : las restricciones de integridad se mantienen en una estructura especial del sistema que consulta el gestor de la base de datos cada vez que tiene lugar una actualizacin en el sistema. Administracin del DBMS A dems de administrar la actividad de datos y la estructura de la BD, el DBA debe administrar el DBMS mismo. Deber compilar y analizar estadsticas relativas al rendimiento del sistema e identificar reas potenciales del problema. Dado que la BD esta sirviendo a muchos grupos de usuarios, el DBA requiere investigar todas las quejas sobre el tiempo de respuesta del sistema, la precisin de los datos y la facilidad de uso. Si se requieren cambios el DBA deber planearlos y ponerlos en practica. El DBA deber vigilar peridica y continuamente las actividades de los usuarios en la BD. Los productos DBMS incluyen tecnologas que renen y publican estadsticas. Estos informes pudieran indicar cuales fueron los usuarios activos, que archivos y que elementos de datos han sido utilizados, e incluso el mtodo 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 modificacin en el diseo 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 estadsticas de tiempo de ejecucin 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 modificacin a la estructura de la BD o al sistema. Casos como la adicin de nuevas claves o su eliminacin, nuevas relaciones entre los datos y otras situaciones tpicas debern ser analizadas para determinar el tipo de modificacin procedente. Cuando el fabricante del DBMS en uso anuncie una nueva versin del producto, debe realizarse un anlisis de las caractersticas que esta incorpora e insopesarlas contra las necesidades de la comunidad de usuarios. Si se decide la adquisicin del producto, los usuarios deben ser notificados y capacitados en su uso. El DBA deber administrar y controlar la migracin tanto de las estructuras, como de los datos y las aplicaciones. El software de soporte y otras caractersticas de hardware pueden implicar tambin modificaciones de las que el DBA es responsable ocasionalmente, estas modificaciones traen como consecuencia cambios en la configuracin o en algunos parmetros de operacin 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 informacin sobre las caractersticas de funcionamiento y respuesta que proporcionar a los grupos de usuarios. El anlisis 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 bsqueda de la optimizacin o afinacin del mismo. Roles o Funciones del Administrador de Base de Datos

Un administrador de bases de datos (o DBA) tiene la responsabilidad de mantener y operar las bases de datos que conforman el sistema de informacin de una compaa. Entre sus roles podemos encontrar:
Recuperabilidad .- Asegurarse de la recuperacion, creando y probando respaldos Integridad .- Verificar o ayudar a la verificacin de integridad de datos Seguridad .- Definir y/o implementar control de acceso Disponibilidad .- Esto es administrar la actividad de la base de datos Desempeo .-Asegurarse del mximo desempeo incluso con las limitaciones Desarrollo y soporte a pruebas .- Ayudar a los programadores e ingenieros a utilizar

eficientemente la base de datos. Incluye administrar la estructura de la base de datos.

Administrar el sistema manejador de base de datos Establecer el diccionario de datos Asegurar la confiabilidad de la base de datos

Ahora detallaremos un poco cada uno de estos roles: Recuperabilidad Esto significa que, si ocurre algn error en los datos, hay un bug de programa de hardware, el DBA (Administrador de base de datos) puede traer de vuelta la base de datos al tiempo y estado en que se encontraba en estado consistente antes de que el dao se causara. El DBA debe definir y poner en practica un plan de recuperacin adecuado que incluya, por ejemplo una descarga o "vaciado" peridico 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 ms reciente cuando sea necesario. Las actividades de recuperacin incluyen el hacer respaldos de la base de datos y almacenar esos respaldos de manera que se minimice el riesgo de dao prdida de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles y almacenarlos fuera del rea en antelacin a un desastre anticipado. La recuperacin es una de las tareas ms importantes de los DBA's. Integridad La integridad de una base de datos significa que, la base de datos los programas que generaron su contenido, incorporen mtodos que aseguren que el contenido de los datos del sistema no se rompan as como las reglas del negocio. Por ejemplo, un distribuidor puede tener una regla la cual permita que solo los clientes individuales puedan solicitar rdenes; a su vez cada orden identifique a uno y solo un proveedor.
Seguridad

La seguridad se encarga de limitar a los usuarios a ejecutar nicamente las operaciones permitidas. Al igual que otros metadatos, una DBMS relacional maneja la seguridad en forma de tablas. Estas tablas son las "llaves del reino" por lo cual se deben proteger de posibles intrusos.extraos Disponibilidad

El DBA debe mantener la disponibilidad, esto significa que los usuarios tengan acceso a los datos cuando lo necesiten para atender a las necesidades del negocio. Desempeo Esto significa que la base de datos no cause tiempos de respuesta poco razonables. En sistemas muy complejos cliente/servidor y de tres capas, la base de datos es solo uno de los elementos que determinan la experiencia de los usuarios en lnea y los programas desatendidos. El desempeoes una de las mayores motivaciones de los DBA para coordinarse con los especialistas de otras reas del sistema fuera de las lneas burocrticas tradicionales. Desarrollo y Soporte a Pruebas Las actividades de soporte incluyen la colecta de datos de produccin para llevar a cabo pruebas con ellos; consultar a los programadores respecto al desempeo; y hacer cambios a los diseos de tablas de manera que se puedan proporcionar nuevos tipos de almacenamientos para las funciones de los programas.
Administrar el sistema manejador de base de datos

La concurrencia de mltiples usuarios requiere la estandarizacin de los procesos de operacin; el DBA es responsable de stas especificaciones y de asegurarse que estas lleguen a quienes concierne. Todo el mbito de la base de datos se rige por estndares, desde la forma de como se captura la informacin (tipo de dato, longitud, formato), como es procesada y presentada. El nivel de estandarizacin alcanza hasta los aspectos ms internos de la base de datos; como s accesa a un archivo, como se determinan los ndices primarios y auxiliares, registros, etc. El DBA debe procurar siempre que los estndares que sern aplicados beneficien tambin a los usuarios, privilegiando siempre la optimizacin en la operacin del DBMS y el apego de las polticas de la empresa. Entre las funciones del DBA se encuentra la de revisar los estndares peridicamente para determinar su operatividad, ajustarlos, ampliarlos o cancelarlos y hacer que stos se cumplan.
Establecer el diccionario de datos

Cuando se definen estndares sobre la estructura de la base de datos, se deben de registrarse en una seccin del diccionario de datos a la que todos aquellos usuarios relacionados con ese tipo de proceso pueden acceder. Este metadato debe precisar informacin que nos indique con claridad el tipo de datos que sern utilizados, sus mbitos de influencia y sus limitantes de seguridad.
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 reparacin de los posibles errores que las bases de datos pueden sufrir, por ejemplo tras un corte inesperado de luz. Modelo de Datos Nociones de Modelamiento El objetivo es producir una descripcin estructurada de la organizacin y del negocio del cliente, en detalle suficiente para permitir construir un sistema basado en ste. Para esto, mnimamente se requiere: Un conjunto de tcnicas especficas y complementarias, adecuadas cada una para describir distintos aspectos del negocio/sistema. Conocimiento, normas y estndares que aseguren la correcta descripcin y posterior interpretacin usando estas tcnicas. Notas

 3. Modelo de Datos Nociones de Modelamiento Modelamiento Entidad - Relacin Modela las cosas acerca de las cuales el negocio mantiene o debe mantener informacin, y las asociaciones existentes entre stas. Notas 4. Modelo de Datos Nociones de Modelamiento Modelamiento Funcional Modela lo que el negocio hace o har en el futuro para alcanzar sus objetivos. Notas 5. Modelo de Datos Nociones de Modelamiento Diagramas de Flujo de Datos Modela el flujo de informacin dentro y fuera del negocio y las transformaciones que sta sufre en el proceso Notas 6. Modelo de Datos Nociones de Modelamiento Matrices de Cruce Muestra las asociaciones entre elementos de distintas clases. Ayuda al control de calidad y a completar los modelos. Notas 7. Modelo de Datos Nociones de Modelamiento Panorama General Notas 8. Modelo de Datos Modelo de Datos Un modelo de datos se define como la combinacin de tres componentes : Una coleccin de tipos de objetos de informacin, los cuales son las unidades bsicas para construir cualquier base de datos. Una coleccin de reglas generales de integridad, las cuales limitan el conjunto de los tipos de objetos que pueden aparecer en forma legal en cualquier base de datos. Una coleccin de operadores, aplicables a los objetos para obtener informacin y para otros propsitos. Notas 9. La descripcin de la estructura de una base de datos, es el modelo de datos, una coleccin de herramientas conceptuales para describir datos, relaciones de datos, semnticas y restricciones de datos. Los principales objetivos del proceso de modelamiento es saber identificar cual es el problema y encontrar la forma de representarlo en un sistema. Esto significa saber de los datos, saber quienes van a usarlos y como van a usarlos. Modelo de Datos Notas 10. Modelo de Datos Notas 11. Modelo Entidad - Relacin El objetivo es identificar y representar las cosas de importancia para el funcionamiento del negocio ( entidades ), sus propiedades ( atributos ), y la forma en que estas cosas se relacionan entre s ( relaciones ). Este modelo se desarroll para facilitar el diseo de las bases de datos (presentado por Chen en 1976). La idea de esta metodologa de representacin de la informacin es mostrar los datos que contendr un sistema como un conjunto de objetos con atributos propios, los cuales son capaces de disminuir la redundancia presente en un sistema de archivos tradicionales y ocupar mejor la estructura presente en los datos a almacenar. Modelo de Datos Modelo Entidad - Relacin Notas 12. Terminologa bsica Entidad Relacin Atributo Identificador nico Subtipo y Supertipo Dependencia de existencia Entidades fuertes y dbiles Qu es una Entidad ? Definiciones Cualquier cosa de relevancia para el negocio acerca de la cual debe mantenerse informacin. Algo con existencia real o conceptual. Algo a lo que se le da nombre. Cualquier cosa que se puede identificar claramente. Un objeto que existe y es distinguible de otros objetos. Modelo de Datos Modelo Entidad - Relacin Notas 13. Cmo se identifican Entidades ? A partir de la descripcin del negocio: Buscando SUSTANTIVOS de uso comn en el negocio. Buscando SINNIMOS, que representen conceptos generalizables. A partir de los documentos del negocio: Buscando agrupaciones de informacin contenida en stos. Buscando elementos de informacin cuyo origen puede estar en entidades no identificadas. Modelo de Datos Modelo Entidad - Relacin Notas

 14. Entidades - Representacin grfica Rectngulo de bordes redondeados. Nombre en singular y maysculas. Modelo de Datos Modelo Entidad - Relacin Notas EMPLEADO PROYECTO PERSONA SALA PROVEEDOR PRODUCTO 15. Atributos Las entidades poseen cualidades o propiedades conocidas como atributos : una sala de clases tiene, un nombre (QO - QP - D310), una ubicacin, un cupo, etc.. Definicin Dato especfico, significativo para una entidad, que: La califica, o (ej.: color) La identifica, o (ej.: RUT) La clasifica, o (ej.: grupo) La cuantifica, o (ej.: peso) Expresa su estado (ej.: pagado, solicitado) Deben llevar nombre en singular, nico dentro de la entidad. No deben incluir el nombre de la entidad. Pueden ser opcionales u obligatorios. Su formato, valores por defecto, rangos, validaciones, son comunes para todos los valores posibles del atributo. Modelo de Datos Modelo Entidad Relacin Notas 16. Atributos - Representacin grfica Modelo de Datos Modelo Entidad - Relacin Notas VEHICULO # Numero Motor Patente Tipo Marca o Modelo o Numero de puertas o Numero de asientos Identificador nico Atributos Obligatorios Atributos Opcionales 17. Atributos Cada atributos de una entidad posee un TIPO, el que corresponde al tipo de dato del atributo. Ejemplo : RUT Nmero Nombre String. Fecha Date. Dominios Dominio es un conjunto de reglas de validacin, restricciones de formato, y otras propiedades que se aplican a un grupo de atributos. Ejemplos : Listas de valores Rangos Los dominios estandarizan los atributos en las entidades del negocio. Modelo de Datos Modelo Entidad - Relacin Notas 18. Conversin de Atributos en Entidades Esto ocurre cuando: El atributo puede tener varios valores dada una ocurrencia de una entidad, o El atributo puede tener a su vez atributos, o Requerimos historia de cambios en los valores del atributo. Relaciones Definicin Una relacin es una asociacin significativa entre dos entidades. Una relacin es una vinculacin entre entidades , por ejemplo, la entidad libro puede estar relacionada con la entidad persona por medio de la relacin arrendar. Modelo de Datos Modelo Entidad - Relacin Notas 19. Toda relacin tiene un nombre , que expresa la asociacin entre las entidades. Tiene grado (o cardinalidad ). Tiene opcionalidad. Formalmente, una relacin R entre conjuntos de entidades {E 1 , E 2 , ... E n } se representa mediante un conjunto de n-tuplas (e 1 , e 2 , ..., e n ) donde e 1 1 , e 2 2 , ..., e n E n . Una relacin tambin puede tener atributos, por ejemplo, en la relacin arrendar el atributo fecha podra indicar la fecha en que se devuelve el libro. Relaciones Representacin grfica Una relacin se representa por una lnea que une dos entidades. La opcionalidad se representa por una lnea punteada (opcional) o llena (obligatoria). Modelo de Datos Modelo Entidad - Relacin Notas 20. El grado se representa por un extremo simple (uno) o pata de gallo (muchos). El nombre se escribe en los extremos. Modelo de Datos Modelo Entidad - Relacin Notas MODELO MARCA corresponder a tener Muchos Uno (pata de gallo) (simple) Obligatorio Opcional (lnea llena) (punteado) 21. Relaciones - Lectura La lectura debe expresar reglas del negocio Cada extremo se lee: Cada ( entidad ) puede , o debe ( nombre relacin ) una o ms , o una y solo una ( entidad(es) ) Ejemplo: Cada MODELO debe corresponder a una y slo una MARCA. Cada MARCA puede tener uno o ms MODELOS. Relaciones Muchos a Muchos Son aquellas cuyo grado es mltiple en ambos extremos. Se deben resolver buscando una entidad de interseccin. Modelo de Datos Modelo Entidad - Relacin Notas

 22. Ejercicios Haga una lista de entidades y atributos para: Una distribuidora de combustibles. Un Banco Falabella 23. Distribuidora de Combustibles Bencina Bomba Direccion Combustible Productos Venta Cliente Sucursal Petrleo Gasolina 95 octanos Kerosene Lavado Aire Nada Entidad Atributo Entidad Entidad Entidad Entidad Entidad Valor de un atributo Valor de un atributo Valor de un atributo Valor de un atributo Valor de un atributo 24. Ejercicio MODELO Codigo_Mod Nombre Descripcion MARCA Codigo_Mar Nombre Descripcion corresponder a tener Muchos Uno (pata de gallo) (simple) Obligatorio Opcional (lnea llena) (punteado) Defina datos coherentes para el siguiente modelo: 1.- El contexto es Vehiculos 2.- Sus datos deben considerar el puede y debe 3.- Si un modelo de vehculo puede pertenecer a ms de una marca, hay que cambiar el modelo de datos? 25. Ejemplo AUTOMOVIL Codigo Patente Nro_Motor Aire_Acc Sun_Roof Air_Bags Frenos_ABS VEHICULO Codigo Patente Nro_Motor Codigo_Acc ACCESORIOS Codigo_ACC Nombre Descripcion VEHICULO Codigo Patente Nro_Motor ACCESORIOS Codigo_ACC Nombre Descripcion ACC_VEH Codigo Codigo_ACC

Conjuntos de entidades (EDM)En el Entity Data Model (EDM), un EntitySet es un contenedor

lgico de las entidades de un nico tipo. De igual forma, un AssociationSet es un contenedor de asociaciones del mismo tipo. Los conjuntos de entidades y asociaciones definidos en esquemas se asignan a las tablas de la base de datos que almacena los datos de las aplicaciones. Los conjuntos de entidades y asociaciones son el fundamento de las clases del modelo de objetos de programacin que se usar en el cdigo de una aplicacin. Los conjuntos de entidades y los conjuntos de asociaciones definen el mbito de las entidades y de las asociaciones; los contenedores de entidades definen los contenedores del almacenamiento que contienen las entidades y las asociaciones. No hay ningn conjunto de SimpleType. Las instancias de estos tipos se crean como valores que se asignan a las propiedades de una entidad. Un EntitySet de un EntityType contiene las instancias del EntityType o cualquiera de sus subtipos. Se puede definir ms de un EntitySet con el mismo EntityType. Una instancia de un EntityType solo puede ser miembro de un EntitySet. Las instancias de entidad de un EntitySet deben satisfacer tres condiciones: El tipo de la instancia de entidad es el EntityType del EntitySet o cualquier subtipo del EntityType. El valor de Key de cada instancia de entidad lo identifica de forma nica en el EntitySet. La instancia de entidad no es miembro de ningn otro EntitySet. La siguiente sintaxis del lenguaje de definicin de esquemas conceptuales (CSDL) es la declaracin de un EntitySet denominado CustomerSet. El EntitySet contiene instancias de la entidad CustomerType: <EntitySet Name="CustomerSet" EntityType="CustomerType"/> En el segmento de esquema siguiente, dos declaraciones de EntityType definen los tipos de entidad Product y Supplier. Los conjuntos de entidades basados en las entidades Product y Supplier se denominan apropiadamente en las formas plurales: Products y Suppliers. Estos conjuntos de entidades se agregan a la definicin de un EntityContainer.

<?xml version="1.0" encoding="utf-8"?> <Schema xmlns:cg="http://schemas.microsoft.com/ado/2006/04/codegeneration" xmlns:edm="http://schemas.microsoft.com/ado/2006/04/edm" xmlns="http://schemas.microsoft.com/ado/2006/04/edm" Namespace="MyCompany.LOBSchema" Alias="Self">

<EntityType Name="Product"> <Key> <PropertyRef Name="ProductID" /> </Key> <Property Name="ProductID" Type="Int32" Nullable="false" /> <Property Name="ProductName" Type="String" Nullable="false" /> <Property Name="UnitPrice" Type="Decimal" Nullable="true" /> <Property Name="UnitsInStock" Type="Int16" Nullable="true" /> </EntityType>

<EntityType Name="Supplier"> <Key> <PropertyRef Name="SupplierID" /> </Key> <Property Name="SupplierID" Type="Int32" Nullable="false" /> <Property Name="CompanyName" Type="String" Nullable="false" /> <Property Name="ContactName" Type="String" Nullable="true" /> <Property Name="HomePage" Type="String" Nullable="true" /> </EntityType>

<EntityContainer Name="LOB-Data"> <EntitySet Name="Products" EntityType="Product" /> <EntitySet Name="Suppliers" EntityType="Supplier" />

</EntityContainer>

</Schema> Mltiples conjuntos de entidades por tipo El Entity Data Model (EDM) permite que se definan para el mismo tipo de entidad varios conjuntos de entidades dentro del contenedor de una sola entidad o de varios contenedores de entidades. La definicin de mltiples conjuntos de entidades por tipo (MEST, Multiple Entity Sets Per Type) permite a los usuarios mejorar su cdigo cuando las bases de datos tienen particiones o en otros escenarios en los que varias tablas tienen la misma estructura. Las bases de datos se dividen en particiones por diversos motivos, como son el rendimiento, la disponibilidad o la facilidad de uso. Una institucin financiera que administra cuentas de un gran nmero de clientes podra dividir en particiones sus sistemas de bases de datos para mejorar el rendimiento en una distribucin regional de datos de clientes. La bsqueda y actualizacin de los datos se agilizarn al restringirse a un subconjunto regional de los datos. Para implementar MEST, las particiones deben crearse dentro de la misma base de datos. Si las particiones tienen lugar a travs de diferentes bases de datos, en lugar de un escenario MEST se requerirn cadenas de conexin y contextos diferentes. Otro escenario en el que la creacin de particiones podra ser de utilidad es cuando un departamento de IT desea realizar cada noche copias de seguridad de los datos a los que se tiene acceso con frecuencia, mientras que los datos a los no se tiene acceso desde hace ms de un ao se archivan. Los administradores de base de datos podran archivar los clientes que no hayan usado los datos de su cuenta durante ms de un ao en una tabla de archivo de la misma base de datos que tenga el mismo esquema de tablas. Es importante considerar la estructura de las asociaciones entre los tipos de entidad que sean miembro de ms de un conjunto de entidades. MEST se implementa con ms facilidad de acuerdo con la estructura que se ha probado. Los escenarios siguientes se han utilizado con xito. En una asociacin uno a varios, una entidad implementada como MEST en el extremo "uno" de una asociacin debera tener una relacin con dos conjuntos de entidades diferentes en el extremo "varios". Por ejemplo, el escenario siguiente puede implementarse con el tipo de entidad Customer en dos conjuntos de entidades: PreferedCustomers y CreditRiskCustomers. PreferedCustomers <1-----*> Orders CreditRiskCustomers <1-----*> CreditReports En una asociacin uno a varios, un conjunto de entidades en el extremo "uno" puede tener una asociacin con una entidad implementada como MEST en el extremo "varios". Por ejemplo, la entidad Product se puede incluir en dos conjuntos de entidades y en asociaciones con la entidad ManufacturingUnit. ManufacturingUnit <1-----*> Products ManufacturingUnit <1----*> DefectiveProducts La implementacin de MEST en un escenario "uno a uno" o "varios a varios" se dificultar al disear el modelo lgico o al asignarlo al modelo conceptual. El problema de implementar MEST

en un escenario uno a uno y varios a varios es el mismo que supone tener MEST en el extremo "uno" con una relacin con el mismo conjunto de entidades en el extremo "varios". En el caso de uno a uno, es posible crear un modelo lgico similar a los casos para uno a varios. En el siguiente escenario de pedidos, se producirn problemas al disear el modelo lgico. PreferedCustomers <1-----*> Orders CreditRiskCustomers <1-----*> Orders El modelo Entidad-Relacin Introduccin al diseo de bases de datos Es sencillo disear una base de datos, pero a menudo hay que reconsiderar posteriormente la estructura de los datos, lo cual ocasiona retrasos y modificaciones. Es ms lento la obtencin de un diseo lo ms ptimo posible, pero el tiempo invertido se recupera al no tener que volver atrs para replantearse el diseo de los datos. Un buen diseo es la clave para iniciar con buen pie el desarrollo de una aplicacin basada en una base de datos o la implementacin de un sistema. Es de destacar la importancia de un buen diseo. Un diseo apresurado o simplemente bosquejado puede mostrarse inservible o muy mejorable cuando la aplicacin ya est parcialmente codificado, o el administrador de la base de datos ya tiene organizados el mantenimiento y el control de acceso a los datos. Esquema: diseo general de la base de datos a nivel lgico. Incluye el tipo de datos y las relaciones entre ellos. Es de naturaleza fija y solo se altera excepcionalmente. El esquema se define y se mantiene utilizando el lenguaje de definicin de datos (DDL). Instancia: contenido concreto de la base de datos en un momento dado. Vara con el tiempo, al aadir, eliminar o modificar datos, utilizando el lenguaje de modificacin de datos (DML). El diseo de una base de datos se realiza a dos niveles. El primero es el nivel conceptual, en la cual se contempla una estructura abstracta y no implementable directamente con un SGBD. El segundo es el nivel fsico, en el cual la base de datos es ya implementable. Detalladamente, las fases del diseo de una base de datos son las siguientes: Descripcin en lenguaje natural. Diagrama Entidad-Relacin (E-R). Tambin conocido como "diagrama de Chen". Estos diagramas modelizan el problema mediante entidades asociadas por relaciones. Adoptan la forma de grafos donde los datos se relacionan mediante flechas. El diagrama E-R no depende del modelo de datos. Eleccin del modelo de datos (usualmente el relacional) Conversin del diagrama E-R al modelo relacional (tablas) Normalizacin (eliminar diversos defectos de diseo). Optimizacin (segn criterios de almacenamiento interno, como el espacio en disco y el tiempo medio de acceso).

Las tres primeras fases pertenecen al nivel conceptual del diseo de bases de datos mientras que las tres ltimas se relacionan con el nivel fsico. Introduccin a los modelos de datos Modelo de datos: estructura general de los datos y tcnicas de acceso proporcionadas por un SGBD. Un SGBD usa siempre un nico modelo de datos. Hay tres modelos de datos posibles: Relacional. Es el ms empleado. Todos los datos visibles al usuario estn organizados estrictamente como tablas de valores. Todas las operaciones sobre la base de datos operan sobre esas tablas. Cada fila de una tabla es una instancia de los datos. Cada columna de una tabla es un atributo (valor indivisible que tiene significado por s solo). Es el modelo de datos ms sencillo y cercano a la forma humana de organizar la informacin. Red. Tambin denominado modelo CODASYL. Fue el primero en aparecer comercialmente, a principios de los aos 70. Se caracteriza por almacenar direcciones de otros datos junto a la misma informacin. Es un modelo cercano al modo de almacenamiento interno del ordenador. Los datos se expresan como registros y las relaciones entre datos como sets. Dos datos estn unidos por una direccin de memoria almacenada al lado de uno de ellos. Esa direccin es la del otro dato. Las direcciones son propias del ordenador, y no tienen sentido lgico para las personas. El tipo de registro es e equivalente a una tabla en el modelo relacional, y se implementa fsicamente mediante un fichero. Jerrquico. Es muy similar al modelo de datos en red, pero con la salvedad de que los registros se organizan con estructura de rbol. El modelo Entidad-Relacin (E-R) Propuesto por Chen a mediados de los aos setenta como medio de representacin conceptual de los problemas y para representar la visin de un sistema de forma global. Fsicamente adopta la forma de un grafo escrito en papel al que se denomina diagrama Entidad-Relacin. Sus elementos fundamentales son las entidades y las relaciones. Una entidad caracteriza a un tipo de objeto, real o abstracto, del problema a modelizar. Toda entidad tiene existencia propia, es distinguible del resto de las entidades, tiene nombre y posee atributos definidos en un dominio determinado. Una entidad es todo aquello de lo que se desea almacenar informacin. En el diagrama E-R las entidades se representan mediante rectngulos. Una relacin es una asociacin o relacin matemtica entre varias entidades. Las relaciones tambin se nombran. Se representan en el diagrama E-R mediante flechas y rombos. Cada entidad interviene en una relacin con una determinada cardinalidad. La cardinalidad (nmero de instancias o elementos de una entidad que pueden asociarse a un elemento de la otra entidad relacionada) se representa mediante una pareja de datos, en minsculas, de la forma (cardinalidad mnima, cardinalidad mxima), asociada a cada uno de las entidades que intervienen en la relacin. Son posibles las siguientes cardinalidades: (0,1), (1,1), (0,n), (1,n), (m,n) . Tambi se informa de las cardinalidades mximas con las que intervienen las entidades en la relacin. El tipo de relacin se define tomando los mximos de las cardinalidades que intervienen en la relacin. Hay cuatro tipos posibles: Una a una (1:1). En este tipo de relacin, una vez fijado un elemento de una entidad se conoce la otra. Ejemplo: nacin y capital.

Una a muchas (1:N). Ejemplo: cliente y pedidos. Muchas a una (N:1). Simetra respecto al tipo anterior segn el punto de visto de una u otra entidad. Muchas a muchas (N:N). Ejemplo: personas y viviendas. Toda entidad debe ser unvocamente identificada y distinguible mediante un conjunto de atributos (quizs un solo atributo) denominado identificador o clave principal o primaria. Puede haber varios posibles identificadores para una misma entidad, en cuyo caso se ha de escoger uno de ellos como identificador principal siendo el resto identificadores alternativos. Ejemplo: dni y nmero de seguridad social de una persona. Hay unas normas de sentido comn a seguir cuando se dibuja un diagrama E-R. La primera es emplear preferentemente lneas rectas en las relaciones y evitar en lo posible que estas lneas se crucen. Se suele usar nombres para describir las entidades y verbos para las relaciones. Esto es lgico ya que las entidades se ponen en comn cuando se realiza alguna accin. Los verbos empleados no necesariamente tienen que ser siempre infinitivos. Ejemplo: Se desea almacenar informacin sobre personas y los coches que eventualmente posean. Una misma persona puede poseer varios coches aunque puede haber personas que no posean ningn coche. Los coches se identifican mediante su nmero de matrcula y las personas mediante su documento nacional de identidad. Todo coche tiene un solo propietario. Se ha de almacener la fecha en que una determinada persona adquiri un determinado coche. Problemas de un esquema nico que agrupe a todos los atributos de la entidad coche (matrcula, marca, modelo, etc.), de la entidad persona (dni, nombre, direccion, etc) y de la relacin entre ambas entidades (fecha de compra). Personas sin coche (valores nulos y gasto de espacio de almacenamiento). Multiplicidad de almacenamiento (redundancia) de los atributos de una persona si sta es propietaria de ms de un coche. Modificacin del valor de un atributo de una persona en una sola de sus apariciones en la instancia de la base de datos (inconsistencia). Para evitar estos problemas se separa el esquema nico de la base de datos en tres separados para coche, persona y la relacin entre ambos, lo que ocasiona otra serie de problemas: Toda matrcula en una instancia concreta del esquema de la relacin entre coches y personas debe aparecer en la instancia del esquema de la entidad coche. Todo dni en una instancia concreta del esquema de la relacin entre coches y personas debe aparecer en la instancia del esquema de la entidad persona. Problemas con la modificacin del valor de una matrcula en la instancia del esquema de la entidad coche. Problemas con la modificacin del valor de un dni en la instancia del esquema de la entidad persona. Problemas con el borrado de varios coches en la instancia concreta del esquema de la entidad coche.

Problemas con el borrado de varias personas en la instancia concreta del esquema de la entidad persona. Una entidad del modelo E-R puede ser fuerte o dbil. Una entidad fuerte existe por s misma sin depender la existencia de alguna otra entidad. Por el contrario la existencia de una instancia de una entidad dbil depende de la existencia previa de otra entidad. Si la entidad dbil puede ser identificada sin necesidad de identificar previamente la entidad de cuya existencia depende, diremos que la entidad dbil lo es por existencia nicamente. Si la entidad dbil no puede ser identificada independientemente, sino que previamente es necesario identificar a la entidad de cuya existencia depende, diremos que la entidad dbil lo es por identificacin. Por extensin se considera que una relacin en la hay entidades dbiles tambin se dice dbil por existencia o por identificacin segn sea el tipo de debilidad de las entidades que intervengan en la relacin. Ejemplos: Se desea almacenar informacin sobre buques petroleros y las refineras donde stos realizan operaciones de descarga de crudo. Un buque puede descargar combustible en cierta cantidad y en una determinada fecha en una de varias refineras. En una misma refinera pueden descargar varios buques. Los buques se identifican mediante una matrcula naval y las refineras mediante un cdigo. Se desea almacenar informacin sobre empresas y sucursales de empresas. Una empresa puede tener varias sucursales repartidas geogrficamente. Una sucursal determinada debe pertenecer a una y solo una empresa. Las sucursales se numeran correlativamente para cada empresa. Se desea almacenar informacin sobre personas y sus viviendas en propiedad. Supondremos que una vivienda tan solo puede pertenecer a una persona y que no toda persona debe ser obligatoriamente propietaria de al menos una vivienda. Idea para el reconocimiento de entidades dbiles: Pensar qu sucede cuando se borra una instancia concreta de la entidad fuerte. Ejemplo: se desea disear una pequena base de datos para almacenar informacin relativa a los estudios universitarios de un colectivo de alumnos pertenecientes a una misma facultad. Un alumno puede cursar a la vez varias asignaturas pertenecientes a cursos distintos. Cada curso se compone de una serie de asignaturas que se imparten en aulas. Las asignaturas se agrupan en reas de conocimiento y los profesores que las imparten se agrupan en departamentos que supondremos no guardan relacin con las reas de conocimiento. No hay asignaturas sin alumnos. Todo profesor debe estar adscrito a un nico departamento. Una asignatura puede ser impartida por varios profesores siempre que stos pertenezcan al mismo departamento. Puede haber profesores que no impartan docencia. Observar que la restriccin de que una asignatura no pueda ser enseada por profesores de departamentos distintos no es expresable en el diagrama E-R. En la realidad deber ser indicada utilizando el DDL cuando se cree la base de datos. El aspecto bsico para elaborar un diagrama E-R es la determinacin de entidades para lo cual se extraen de la descripcin verbal del sistema los nombres comunes y entre ellos se escogen los que claramente aporten informacin valiosa. Con el resto de nombres se utiliza el sentido comn descartando los intiles. En caso de duda, es mejor incluir una entidad que posteriormente se revele como innecesaria que perder informacin relevante al problema. Un atributo que lgicamente pueda estar en varias entidades se ubicar finalmente en la entidad en la que sea ms fijo, es decir, en la que est ms ligado al resto de atributos de esa entidad. Por

sentido comn pueden aadirse atributos que no aparezcan citados expresamente en la descripcin verbal del problema. Muchas veces es posible simplificar el diagrama E-R eliminando entidades innecesarias. Por ejemplo, si una entidad que interviene nicamente en una relacin del tipo una a una (1:1) no tiene como atributo ms que su cdigo, este atributo puede incluirse en la entidad con la que est relacionada elimianar tanto la relacin como la entidad. Tipos especiales de relacin Relacin reflexiva o recursiva. Relaciona una entidad consigo misma. Ejemplo: empleados que pueden ser jefes de otros empleados. Dos relaciones entre las mismas dos entidades. Muy til en el caso de necesitar almacenar informacin histrica completa. Ejemplo: proyectos en los que trabaja actualmente un empleado y proyectos en los que ha trabajado anteriormente. Relacin ternaria. Asociacin de tres entidades. La forma de hallar cardinalidades en las relaciones ternarias es fijar una combinacin de elementos en dos de los extremos de la relacin y obtener lgicamente las cardinalidades mnima y mxima en el otro extremo libre. Ejemplo: el ttulo de un libro, un autor y una editorial se relacionan las tres mediante la accin de publicar el libro (en un ao concreto, con un ISBN y con un determinado nmero de pginas en la edicin). Para determinar las cardinalidades hay que preguntarse por: Cuntos autores puede tener un determinado libro editorial(cardinalidd en el extremo de la entidad autor). publicado en una determinada

Cuntos libros puede tener un determinado autor publicados en una determinada editorial (cardinalidad en el extremo de la entidad libro). En cuntas editoriales puede un determinado autor publicar un mismo libro (cardinalidad en el extremo de la entidad editorial). Relacin de especializacin (ES-UN). Tipificacin de una entidad en en subtipos en nmero finito y conocido. Cada subtipo puede poseer atributos propios que. Los subtipos heredan los atributos que pudiera tener la entidad general. Este tipo de relacin puede clasificarse de dos maneras distintas. La primera se segn si una instancia o elemento concreto de la entidad puede ser de ms de un subtipo a la vez. En caso afirmativo se dice que la relacin es inclusiva o con solapamiento mientras que en caso contrario ser exclusiva o sin solapamiento. La segunda clasificacin se basa en si obligatoriamente cada instancia o elemento concreto debe ser obligatoriamente de alguno de los subtipos especificados, es decir, si no pueden existir elementos de la entidad que no pertenezcan a ninguno de los subtipos. Si es as la relacin se dice total y en caso contario parcial. La situacin ms corriente en una relacin de especializacin es que sea exclusiva y total. Ejemplos: Una entidad persona tiene los subtipos hombre y mujer. Una misma persona no puede ser hombre y mujer a la vez por lo que la relacin es exclusiva. No puede existir una persona que no sea hombre ni mujer, por lo que tambin es total. Se conviene en que un vehculo puede ser un coche, un camin o una moto. La relacin es claramente exclusiva (un vehculo no puede ser coche y camin a la vez, ni camin y moto, etc) y parcial pues puede haber vehculos que no sean ni coche ni camin ni moto.

La entidad que representa a un universitario tiene los subtipos profesor y estudiante. Un mismo universitario puede ser ambas cosas a la vez (p.e. un profesor puede estar matriculado como alumno en alguna facultad) por lo que la relacin es inclusiva. No puede existir un universitario que no sea ni profesor ni estudiante, por lo que tambin es total. Expresamos mediante una relacin de especializacin el que una funcin matemtica tiene asociados los subtipos continua y derivable. La relacin es inclusiva pues una misma funcin puede ser ambas cosas a la vez, y parcial porque existen funciones que no son continuas ni derivables. Supongamos una entidad A que se especializa en dos subtipos A1 y A2. La identificacin del tipo de relacin (exclusiva, total, etc) puede hacerse atendiendo a la siguiente tabla de verdad: A1 No No S S A2 No S No S Caso posible? S No -> Total S S S -> No -> Exclusiva Inclusiva -> Parcial

La cardinalidad en las relaciones de especializacin es siempre (1,1) en el extremo de la entidad que se especializa en subtipos y (0,1) en el extremo de los subtipos si la relacin es exclusiva o ({0,1},1) si es inclusiva. Una relacin de especializacin parcial puede fcilmente convertirse en total aadiendo un nuevo subtipo "otros". Ejemplo: Una empresa desea almacenar informacin sobre sus clientes y los pedidos que stos realizan. Un pedido consta de un nmero variable de artculos deseados en una determinada cantidad. La empresa guarda un determinado nmero de unidades de cada artculo en su almacn. Puede ser que la cantidad realmente servida de un artculo en un pedido sea inferior a la cantidad pedida si no hay suficiente stock. Los pedidos pueden ser urgentes, en cuyo caso se especifica adems un nmero mximo de das que el cliente est dispuesto a esperar el servicio del pedido. Un diagrama o modelo entidad-relacin (a veces denominado por sus siglas en ingls, E-R "Entity relationship", o del espaol DER "Diagrama de Entidad Relacin") es una herramienta para el modelado de datos que permite representar las entidades relevantes de un sistema de informacin as como sus interrelaciones y propiedades.
Modelado Entidad-Relacin

El Modelo Entidad-Relacin. Se elabora el diagrama (o diagramas) entidad-relacin. Se completa el modelo con listas de atributos y una descripcin de otras restricciones que no se pueden reflejar en el diagrama. El modelado de datos no acaba con el uso de esta tcnica. Son necesarias otras tcnicas para lograr un modelo directamente implementable en una base de datos. Brevemente:

Transformacin de relaciones mltiples en binarias. Normalizacin de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa). Conversin en tablas (en caso de utilizar una base de datos relacional).
Base terica y conceptual

El modelo de datos entidad-relacin est basado en una percepcin del mundo real que consta de una coleccin de objetos bsicos, llamados entidades, y de relaciones entre esos objetos.
Entidad

Representa una cosa u "objeto" del mundo real con existencia independiente, es decir, se diferencia unvocamente de otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad. Algunos Ejemplos: Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos). Un automvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrn atributos diferentes, por ejemplo, el nmero de chasis). Una casa (Aunque sea exactamente igual a otra, an se diferenciar en su direccin). Una entidad puede ser un objeto con existencia fsica como: una persona, un animal, una casa, etc. (entidad concreta); o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un nombre,etc. (entidad abstracta). Una entidad est descrita y se representa por sus caractersticas o atributos. Por ejemplo, la entidad Persona las caractersticas: Nombre, Apellido, Gnero, Estatura, Peso, Fecha de nacimiento, etc...
Atributos

Los atributos son las caractersticas que definen o identifican a una entidad. Estas pueden ser muchas, y el diseador solo utiliza o implementa las que considere ms relevantes. Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades. En un conjunto de entidades, cada entidad tiene valores especficos asignados para cada uno de sus atributos, de esta forma, es posible su identificacin unvoca. Ejemplos: A la coleccin de entidades alumnos, con el siguiente conjunto de atributos en comn, (id, nombre, edad, semestre), pertenecen las entidades: (1, Sofa, 38 aos, 2) (2, Josefa, 19 aos, 5) (3, Carlos, 20 aos, 2) Cada una de las entidades pertenecientes a este conjunto se diferencia de las dems por el valor de sus atributos. Ntese que dos o ms entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos.

En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su nmero de id. Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que ser almacenado o a restricciones en los valores que el atributo puede tomar (cadenas de caracteres, nmeros, solo dos letras, solo nmeros mayores que cero, solo nmeros enteros...). Cuando algn atributo correspondiente a una entidad no tiene un valor determinado, recibe el valor nulo, bien sea porque no se conoce, porque no existe o porque no se sabe nada al respecto del mismo.
Relacin

Describe cierta dependencia entre entidades o permite la asociacin de las mismas. Ejemplo: Dadas dos entidades "Habitacin 502" y "Henry Jonshon Mcfly Bogard", es posible relacionar que la habitacin 502 se encuentra ocupada por el husped de nombre Henry. Una relacin tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, un husped (entidad), se aloja (relacin) en una habitacin (entidad).
Conjunto de relaciones Consiste en una coleccin, o conjunto, de relaciones de la misma naturaleza.

Ejemplo: Dados los conjuntos de entidades "Habitacin" y "Husped", todas las relaciones de la forma habitacin-husped, permiten obtener la informacin de los huspedes y sus respectivas habitaciones. La dependencia o asociacin entre los conjuntos de entidades es llamada participacin. En el ejemplo anterior los conjuntos de entidades "Habitacin" y "Husped" participan en el conjunto de relaciones habitacin-husped. Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades participantes en la relacin.
Restricciones

Son reglas que deben mantener los datos almacenados en la base de datos.
Correspondencia de cardinalidades

Dado un conjunto de relaciones en el que participan dos o ms conjuntos de entidades, la correspondencia de cardinalidad indica el nmero de entidades con las que puede estar relacionada una entidad dada. 8) Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser: Uno a Uno: Una entidad de A se relaciona nicamente con una entidad en B y viceversa (ejemplo relacin vehculo - matrcula: cada vehculo tiene una nica matrcula, y cada matrcula est asociada a un nico vehculo).

Uno a varios: Una entidad en A se relaciona con cero o muchas entidades en B. Pero una entidad en B se relaciona con una nica entidad en A (ejemplo vendedor - ventas). Varios a Uno: Una entidad en A se relaciona exclusivamente con una entidad en B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en A (ejemplo empleado-centro de trabajo). Varios a Varios: Una entidad en A se puede relacionar con 0 o muchas entidades en B y viceversa (ejemplo asociaciones- ciudadanos, donde muchos ciudadanos pueden pertenecer a una misma asociacin, y cada ciudadano puede pertenecer a muchas asociaciones distintas).
Restricciones de participacin

Dado un conjunto de relaciones R en el cual participa un conjunto de entidades A, dicha participacin puede ser de dos tipos: Total: Cuando cada entidad en A participa en al menos una relacin de R. Parcial: Cuando al menos una entidad en A NO participa en alguna relacin de R.
Claves

Es un subconjunto del conjunto de atributos comunes en una coleccin de entidades, que permite identificar unvocamente cada una de las entidades pertenecientes a dicha coleccin. Asimismo, permiten distinguir entre s las relaciones de un conjunto de relaciones. Dentro de los conjuntos de entidades existen los siguientes tipos de claves: Superclave: Es un subconjunto de atributos que permite distinguir unvocamente cada una de las entidades de un conjunto de entidades. Si se aade un atributo al anterior subconjunto, el resultado seguir siendo una superclave. Clave candidata: Dada una superclave, si sta deja de serlo quitando nicamente uno de los atributos que la componen, entonces sta es una clave candidata. Clave primaria: Es una clave candidata, elegida por el diseador de la base de datos, para identificar unvocamente las entidades en un conjunto de entidades. Los valores de los atributos de una clave, no pueden ser todos iguales para dos o ms instancias. Para poder distinguir unvocamente las relaciones en un conjunto de relaciones R, se deben considerar dos casos: R NO tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de las claves primarias de todos los conjuntos de entidades participantes. R tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de los atributos asociados y las claves primarias de todos los conjuntos de entidades participantes. Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria est compuesto de relaciones binarias, con los conjuntos de entidades participantes A y B, se consideran los siguientes casos, segn sus cardinalidades: R es de muchos a uno de A a B entonces slo se toma la clave primaria de A, como clave primaria de R.

R es de uno a muchos de A a B entonces se toma slo la clave primaria de B, como clave primaria de R. R es de uno a uno de A a B entonces se toma cualquiera de las dos claves primarias, como clave primaria de R. R es de muchos a muchos de A a B entonces se toma la unin de los atributos que conforman las claves primarias de A y de B, como clave primaria de R.
Diagrama entidad-relacin

Anteriormente detallamos los conceptos relacionados al modelo ER, en esta seccin profundizaremos en como representarlos grficamente. Cabe destacar que para todo proceso de modelado, siempre hay que tener en claro los conceptos, estos nos brindan conocimiento necesario y adems fundamentan nuestro modelo al momento de presentarlo a terceros. Formalmente, los diagramas ER son un lenguaje grfico para describir conceptos. Informalmente, son simples dibujos o grficos que describen informacin que trata un sistema de informacin y el software que lo automatiza.
Entidades

Las entidades son el fundamento del modelo entidad relacin. Podemos adoptar como definicin de entidad cualquier cosa o parte del mundo que es distinguible del resto. Por ejemplo, en un sistema bancario, las personas y las cuentas bancarias se podran interpretar como entidades. Las entidades pueden representar entes concretos, como una persona o un avin, o abstractas, como por ejemplo un prstamo o una reserva. Se representan por medio de un rectngulo.
Atributos

Se representan mediante un crculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta. Por motivos de legibilidad, los atributos suelen no aparecer representados en el diagrama entidadrelacin, sino descritos textualmente en otros documentos adjuntos.
Relaciones

Se representan mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir mediante lneas con las entidades (rectngulos) que relaciona, para as saber cul es la relacin que lleva cada uno.
Diagramas extendidos

Los diagramas Entidad-Relacin no cumplen su propsito con eficacia debido a que tienen limitaciones semnticas. Por ese motivo se suelen utilizar los diagramas Entidad-Relacin extendidos que incorporan algunos elementos ms al lenguaje:
Entidades fuertes y dbiles

Cuando una entidad participa en una relacin puede adquirir un papel fuerte o dbil. Una entidad dbil es aquella que no puede existir sin participar en la relacin; es decir, aquella que no puede ser unvocamente identificada solamente por sus atributos.

Una entidad fuerte (tambin conocida como entidad regular) es aquella que s puede ser identificada unvocamente. En los casos en que se requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad dbil para que esta ltima se pueda identificar. Las entidades dbiles se representan- mediante un doble rectngulo; es decir, un rectngulo con doble lnea. Se puede hablar de la existencia de 2 tipos de dependencias en las entidades dbiles: Dependencia por existencia. Las ocurrencias de la entidad dbil pueden identificarse mediante un atributo identificador clave sin necesidad de identificar la entidad fuerte relacionada. Dependencia por identificacin. La entidad dbil no puede ser identificada sin la entidad fuerte relacionada. (Ejemplo: si tenemos una entidad LIBRO y otra relacionada EDICIN, para identificar una edicin necesitamos conocer el identificador del libro).
Cardinalidad de las relaciones

El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relacin, respectivamente: "1:1", "1:N" y "N:M", aunque la notacin depende del lenguaje utilizado, la que ms se usa actualmente es el unificado. Otra forma de expresar la cardinalidad es situando un smbolo cerca de la lnea que conecta una entidad con una relacin: "0" si cada instancia de la entidad no est obligada a participar en la relacin. "1" si toda instancia de la entidad est obligada a participar en la relacin y, adems, solamente participa una vez. "N" , "M", "*" si cada instancia de la entidad no est obligada a participar en la relacin y puede hacerlo cualquier nmero de veces. Ejemplos de relaciones que expresan cardinalidad: Cada esposo (entidad) est casado (relacin) con una nica esposa (entidad) y viceversa. Es una relacin 1:1. Una factura (entidad) se emite (relacin) a una persona (entidad) y slo una, pero una persona puede tener varias facturas emitidas a su nombre. Todas las facturas se emiten a nombre de alguien. Es una relacin 1:N. Un cliente (entidad) puede comprar (relacin) varios servicios (entidad) y un servicio puede ser comprado por varios clientes distintos. Es una relacin N:M.
Atributos en relaciones

Las relaciones tambin pueden tener atributos asociados. Se representan igual que los atributos de las entidades. Un ejemplo tpico son las relaciones de tipo "histrico" donde debe constar una fecha o una hora. Por ejemplo, supongamos que es necesario hacer constar la fecha de emisin de una factura a un cliente, y que es posible emitir duplicados de la factura (con distinta fecha). En tal caso, el atributo "Fecha de emisin" de la factura debera colocarse en la relacin "se emite".

Herencia

La herencia es un intento de adaptacin de estos diagramas al paradigma orientado a objetos. La herencia es un tipo de relacin entre una entidad "padre" y una entidad "hijo". La entidad "hijo" hereda todos los atributos y relaciones de la entidad "padre". Por tanto, no necesitan ser representadas dos veces en el diagrama. La relacin de herencia se representa mediante un tringulo interconectado por lneas a las entidades. La entidad conectada por el vrtice superior del tringulo es la entidad "padre". Solamente puede existir una entidad "padre" (herencia simple). Las entidades "hijo" se conectan por la base del tringulo.
Agregacin

Ejemplo agregacin Es una abstraccin a travs de la cual las relaciones se tratan como entidades de un nivel ms alto. Se utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Se representa englobando la relacin abstrada y las entidades que participan en ella en un rectngulo. En la figura se muestra un ejemplo de agregacin en el que se representa la situacin en la que un profesor, cuando est impartiendo una clase, puede poner una incidencia ocurrida a lo largo de sta (se fue la luz, falta la configuracin de un determinado software, etc.). Multiplicidad de Relaciones Muchos a muchos Muchos a uno Uno a uno