Modelado de datos en base de datos

1. Modelado de datos Manuel Williams Alcedo

2. Modelado de datos Definición: Es el proceso de analizar los aspectos de interés para una organización y la relación que tienen unos con otros. Resulta en el descubrimiento y documentación de los recursos de datos del negocio. El modelado hace la pregunta " Qué ? " en lugar de " Cómo ? ", esta última orientada al procesamiento de los datos. Es una tarea difícil, bastante difícil, pero es una actividad necesaria cuya habilidad solo se adquiere con la experiencia Metas y beneficios: Registrar los requerimientos de datos de un proceso de negocio. Dicho proceso puede ser demasiado complejo y se tendrá que crear un "enterprise data model", el cual deberá estar constituído de líneas individuales. Permite observar: Patrones de datos Usos potenciales de los datos

3. Modelo de implementación El modelado de datos es uno de los elementos más importantes a la hora de iniciar el desarrollo de cualquier proyecto. Esta es la estructura, sobre la que realmente reside la verdadera esencia de la aplicación. Incluso determina si el proyecto va a cumplir con su verdadero objetivo. El modelado de datos es una técnica independiente de la implementación a la base de datos. Esto es importante, porque la metodología L5, siempre busca que se saque el máximo provecho de diversas herramientas. En particular, el esquema final y su implementación pueden sufrir cambios sin afectar de manera drástica la Lógica de Programación Uno de los puntos importantes que se deben indicar es que el modelado de los datos, debe ser llevado como una guía general. Para los profesionales expertos, esto implica el desarrollo de los Diagramas de Entidades y del Modelo Entidad-Relación. Independientemente de la metodología a utilizar, esta herramienta siempre será importante, para entender las relaciones entre las diversas entidades en la Base de Datos.

4. Cómo definir el esquema de la Base de Datos Cuando definimos el Esquema de la Base de Datos estamos implementando en el lenguaje SQL del SGBD, el esquema de Modelado de Datos, anteriormente mencionado. Es preciso notar que se define “en el lenguaje SQL del SGBD”, este punto es importante que sea ampliado. Todos los SGBD, tienen diferencias finales en cuanto a la sintaxis que se maneja. Sabemos que SQL es uno solo y que por eso es estándar, pero las diferentes distribuciones lo han implementado con ciertas variaciones. Están variaciones, son una de las causas en que el modelo de desarrollo, ha separado el Modelado de los Datos, con la Lógica de programación El esquema de la Base de Datos, debe a mi parecer ser definido en el lenguaje SQL de nuestro Sistema Gestor de Base de Datos. La razón es básicamente sencilla: es más portable. Si lo hiciésemos en una aplicación nativa para un sistema operativo en especial y tratáramos de implementarlo directamente en otro sistema, podríamos llegar a tener complicaciones. Es importante destacar, que no se trata de realizar todas las instrucciones SQL, en herramientas como Bloc de Notas. Muchas herramientas que podamos utilizar, nos permitirán exportar nuestra implementación a un archivo, que contendrá la sintaxis SQL. Además, si que sería destacable que como Administradores Generales de la Base de Datos, conociésemos de la sintaxis misma del lenguaje.

5. Herramientas que simplifican el trabajo Al final, si utilizamos una herramienta que nos simplifique el proceso de implementación, siempre será importante guardar un archivo, con las sentencias SQL generadas por la misma. De hecho, con cada modificación debemos guardar una copia de respaldo. Herramientas web como PHPMyAdmin, son muy importantes. La implementación y las pruebas generalmente las realizaremos en un computador local y vía interfaz web, podremos hacer el cambio desde el mismo Servidor instantáneamente y transparente al usuario.

6. Por qué optimizar Creo firmemente que la labor como desarrolladores es que los productos, superen las expectativas de nuestros clientes. La optimización de la base de datos no escapa al proceso de optimización. Un mal proceso de optimización a la Base de Datos, generará que el sistema sea inestable, poco fiable, con posibilidad de la información duplicada, lento para las transacciones, etc. Ahora bien, en el Modelo de Desarrollo la razón por la cual es necesario optimizar, es por que el modelo ve que cada aplicación no está exenta a ser actualizada. Las aplicaciones, entornos de desarrollo y tecnologías van cambiando considerablemente. No podemos pretender que nuestro proyecto, siga funcionando por la eternidad en la versión del sistema en la que lo dejamos. El hacer tal cosa, solamente demostrará una mala calidad de trabajo y poca visión sobre el futuro de nuestra aplicación. Los SGBD no cambian tan vertiginosamente, como otras tecnologías. Por lo cual, optimizar nos permitirá hacer un sistema adaptable, que utilice lo mejor del sistema y que pueda escalar sin problemas, dentro de un corto plazo, cuando veamos que la nueva versión, cumple y sobrepasa nuestras expectativas. Debemos siempre estar abiertos al cambio, pero utilizar lo mejor que haya en el momento presente.

7. Las bases de datos son necesarias para - El almacenamiento de grandes cantidades de informacion. - La recuperacion rapida y flexible de informacion. - La organizacion y reorganizacion de la informacion. - La impresion y distribucion de informacion en varias formas.programa de base de datos: Es una herramienta de software para organizar el almacenamiento y la recuperacion de esa informacion.Lasbases de datos se aplican en las industrias, bancos locales ynacionales, compañias manofactureras, empresas e instituciones, redesde bancos, etc.Desde computadoras personales y en situaciones mascomplejas donde se requiere que muchos usuarios compartan lainformacion, utilizan computadoras multiusuario ya sea, mainframes,minis o redes.

8. OBJETIVOS DEL DISEÑO DE BASES DE DATOS Entre las metas más importantes que se persiguen al diseñar un modelo de bases de datos, se encuentran las siguientes que pueden observarse en esta figura.

9. CONCEPTOS IMPORTANTES Base de Datos.- Cualquier conjunto de datos organizados para su almacenamiento en la memoria de un ordenador o computadora, diseñado para facilitar su mantenimiento y acceso de una forma estándar. Los datos suelen aparecer en forma de texto, números o gráficos. Hay cuatro modelos principales de bases de datos: el modelo jerárquico, el modelo en red, el modelo relacional (el más extendido hoy en día). Base de Datos Relacional.- Tipo de base de datos o sistema de administraciónde bases de datos, que almacena información en tablas (filas y columnas de datos) y realiza búsquedas utilizando los datos de columnas especificadas de una tabla para encontrar datos adicionales en otra tabla. Datos Elementales.-Un dato elemental, tal como indica su nombre, es una pieza elemental de información. El primer paso en el diseño de una base de datos debe ser un análisis detallado y exhaustivo de los datos elementales requeridos. Campos y Subcampos.- Los datos elementales pueden ser almacenados en campos o en subcampos. Un campo es identificado por un rótulo numérico que se define en la FDT de la base de datos. A diferencia de los campos, los subcampos no se identifican por medio de un rótulo, sino por un delimitador de subcampo. Delimitador de Subcampo.- Un delimitador de subcampo es un códigode dos caracteres que precede e identifica un subcampo de longitud variable dentro de un campo. DBMS: Data Base Management System (SISTEMA DE MANEJO DE BASE DE DATOS)

10. Análisis de las necesidades En reunión con el cliente se deben documentar los tres grupos de usuarios definidos en la introducción de la guía, las necesidades de información de cada uno de ellos, así como los informes que cada uno necesita para su actividad y el contenido de los mismos. Cuanta más precisión exista en estos requisitos iníciales más preciso será el desarrollo de la base de datos. En esta reunión también debe quedar documentados los niveles de seguridad de los grupos de usuarios, los derechos de cada uno de ellos sobre los datos, los requisitos de los sistemas informáticos del cliente (sistema operativo, tipo de red, servidores, etc.) y la ubicación de los usuarios.

11. Modelo Entidad-Relación Definición Generalmente todo modelo tiene una representación gráfica, para el caso de datos el modelo más popular es el modelo entidad-relación o digrama E/R. Se denomina así debido a que precisamente permite representar relaciones entre entidades (objetivo del modelado de datos). El modelo debe estar compuesto por: Entidades Atributos Relaciones Cardinalidad Llaves 2.2.2 Conjuntos de entidades y atributos Entidades: todo lo que existe y es capaz de ser descrito (sustantivo). Atributos: es una característica (adjetivo) de una entidad que puede hacer 1 de tres cosas: Identificar Relacionar Describir

12. Conjuntos de relaciones

13. Enfoque de red Este modelo fue el resultado de estandarización del comité CODASYL. Aunque existen algunos DBMSs de red que no siguen las especificaciones CODASYL, en general, una base de datos CODASYL es sinónimo de base de datos de red. El modelo de red intenta superar las deficiencias del enfoque jerárquico, permitiendo el tipo de relaciones de muchos a muchos. Una estructura de datos en red, o estructura plex, es muy similar a una estructura jerárquica, de hecho no es más que un superconjunto de ésta. Al igual que en la estructura jerárquica, cada nodo puede tener varios hijos pero, a diferencia de ésta, también puede tener varios padres. La Figura 4.9 muestra una disposición plex. En esta representación, los nodos C y F tienen dos padres, mientras que los nodos D, E, G y H tienen sólo uno.

14. Conceptos básicos: tuplas, relaciones, atributos Como ya hemos mencionado, el modelo relacional está basado en la teoría de conjuntos. En este modelo, los datos se organizan en un tipo especial de conjunto denominado relación, (relation) que se define de la siguiente manera: sean los conjuntos D1,..., Dn, denominados dominios, que no tienen por qué ser distintos entre sí. Una relación definida sobre D1,...,Dn es cualquier subconjunto R de D, donde n es el grado o aridad de R. Los dominios son en principio conjuntos finitos de datos. Por tanto, a menos que se indique lo contrario, presumimos que las relaciones son también finitas. Los elementos de una relación se denominan tuplas. Formalmente, una tupla es: < d1,..., dn>, donde d1D1,..., dnDn El número de tuplas en una relación es la cardinalidad de la relación. Puesto que una relación es un conjunto, los elementos de este conjunto, las tuplas, han de ser por fuerza distintas. Esto también implica que el orden de las tuplas es irrelevante. El conjunto vacío es una relación particular: la relación nula o vacía. Cada tupla de una relación, junto con el nombre de la relación, representa una aserción (en el sentido lógico). Por ejemplo, cada tupla en la relación PROFESORES, es una aserción de que la entidad (profesor) dx es miembro de la institución Dx y tiene las propiedades atómicas <v1,..., vn>.14

15. Claves primaria Puesto que las tuplas son irrepetibles, una relación necesita un identificador único para cada una de las tuplas, esta es la clave (primaria) de la relación, que se define como un subconjunto C de los atributos de R, cuyos valores no pueden ser repetidos. Una clave primaria debe ser mínima, en el sentido de que en su composición no intervengan más que los atributos estrictamente requeridos para identificar las tuplas de forma única. Puesto que una relación es un conjunto de tuplas, se debe dar la condición de que toda relación deba tener una clave primaria; al menos el conjunto de los atributos de una relación conforma la clave de esa relación. Además, una clave primaria puede ser simple (formada por un solo atributo) o compuesta (formada por más de uno). Las dos características definitorias son, por tanto, la unicidad y la minimalidad (Date 1990). La cuestión de si una clave primaria debe ser semántica o no sigue siendo fuente de discusiones. Una clave semántica, también llamada inteligente, es aquella que tiene significado por sí misma, independientemente de que sea o no la clave, es decir que el o los atributos que la conformen contengan valores que describan "realmente" a la entidad reflejada en la tupla (por ejemplo, los apellidos o el DNI en una relación que denote personas). Lo contrario, es decir, una clave arbitraria cuya única función es la de identificar la entidad designada por la tupla, se denomina clave subrogada. Muchos proponentes del modelo relacional, entre ellos (Date 1991) opinan que usar una clave inteligente puede llegar a desorganizar una base de datos si se producen cambios en los datos y abogan por la utilización exclusiva de claves subrogadas; para estos autores este tipo de claves tiene el beneficio de poder ser modificadas con más facilidad. Otros autores no menos relevantes, como (Celko 1994), miembro del ANSI X3H2 DatabaseStandardsCommittee, esgrimen sólidos argumentos a favor del uso de claves semánticas : Ahorro de espacio puesto que en cualquier caso la información en cuestión ha de ser almacenada en algún lugar.

16. Bases de conocimiento: Esquemas de Representación Como mencionábamos en el apartado anterior, la necesidad de una notación precisa para representar el conocimiento se hizo evidente en el ámbito de la IA casi desde el principio, sin duda debido a la experiencia acumulada en el terreno de las bases de datos. Esta notación recibe el nombre de esquema de representación en el entorno de las bases de conocimiento. En este sentido, resulta práctico considerar una base de conocimiento como un modelo de un mundo/empresa/sección de la realidad (Mylopoulos & Levesque 1984). Hemos de considerar el mundo/universo como una colección de individuos y una colección de relaciones que existen entre esos individuos. La colección de individuos que conforman el universo a representar y las relaciones que éstos mantienen constituye un estado, y puede haber transformaciones de estado que causan la creación o modificación de individuos o de las relaciones entre ellos. Podemos clasificar los esquemas de representación dependiendo de cuál sea el punto de partida: Asignación de valores veritativos sobre estados: esquemas de representación lógicos. Individuos/relaciones: esquema de representación de redes semánticas. Transformaciones de estados: esquemas de representación procedimentales (sistemas productivos). La utilidad de un determinado esquema de representación se centra en dos aspectos (Obermeier 1989:23): Su capacidad o adecuación expresiva, es decir, lo que el sistema puede "entender" o "decir". Su eficacia notacional.

17. Esquemas de redes semánticas Los responsables de los primeros esquemas de representación formalizados fueron Quillian (1968) y Shapiro & Woddmansee (1971). Los esquemas de redes semánticas tienen una fundamentación psicológica muy sólida, tal y como apuntábamos en el Capítulo 2, por lo que se han realizado numerosos esfuerzos por llevar a cabo implementaciones importantes basadas en ellas. Las redes semánticas han sido muy utilizadas en IA para representar el conocimiento y por tanto ha existido una gran diversificación de técnicas. Los elementos básicos que encontramos en todos los esquemas de redes son: Estructuras de datos en nodos, que representan conceptos, unidas por arcos que representan las relaciones entre los conceptos. Un conjunto de procedimientos de inferencia que operan sobre las estructuras de datos. Básicamente, podemos distinguir tres categorías de redes semánticas: Redes IS-A, en las que los enlaces entre nodos están etiquetados. Grafos conceptuales: en los que existen dos tipos de nodos: de conceptos y de relaciones Redes de marcos: en los que los puntos de unión de los enlaces son parte de la etiqueta del nodo.

18. Clasificación de los Modelos de Datos MODELO DE DATOS EXTERNO * (punto de vista de cada usuario en particular) GLOBAL * (punto de vista del conjunto de usuarios -empresa-) INTERNO * (punto de vista de la máquina)

19. Propiedades de un Modelos de Datos ESTÁTICAS a.1) Elementos permitidos • Objetos • Asociaciones • Características de los objetos • Dominios a.2) Elementos no permitidos e restricciones • Inherentes • De integridad o semánticas b) DINÁMICAS (conjunto de operadores). Cada operador tiene dos componentes: • Localización • Acción

20. Relación entre MD y Lenguajes de Datos LD = MD + Sintaxis Ejemplos: SQL = MDR + Sintaxis QUEL = MDR + Sintaxis OQL = MO + Sintaxis