1 / 26

Fundamentos de bases de datos

Fundamentos de bases de datos. Conceptos Básicos UTL Lic. Ricardo Mena Martínez. FUNDAMENTOS DE BASES DE DATOS . 1.1. CONCEPTOS BÁSICOS El almacenamiento y control de información es una tarea común que se realiza en las grandes

Télécharger la présentation

Fundamentos de bases de datos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Fundamentos de bases de datos Conceptos Básicos UTL Lic. Ricardo Mena Martínez.

  2. FUNDAMENTOS DE BASES DE DATOS. • 1.1. CONCEPTOS BÁSICOS • El almacenamiento y control de información es una tarea común que se realiza en las grandes empresas, instituciones, organizaciones, pequeñas oficinas y hasta en nuestra vida personal.

  3. Anteriormente podíamos ver los grandes archiveros con cientos de folders que una secretaria intentaba mantener organizados. Al tratar de automatizar el proceso de manejo de estos archivadores manuales, con objeto de proporcionar un acceso más eficiente a la información surgió la idea de crear los sistemas de archivos como un conjunto de programas que manejaran sus propios datos de manera descentralizada; es decir; cada departamento manejaba su propia información. Esto hizo que existiera como primer inconveniente una gran cantidad de información repetida.

  4. 1.1.1. CONCEPTO DE BASE DE DATOS • A raíz de esto se comenzó a descubrir una serie de inconvenientes que mostraban los sistemas de archivos: • • Separación y aislamiento de los datos. Cuando los datos se separan en distintos archivos, es más complicado acceder a ellos, ya que el programador de aplicaciones debe sincronizar el procesamiento de los distintos archivos implicados para asegurar que se extraen los datos correctos.

  5. Duplicación de datos. La redundancia de datos existente en los sistemas de archivos hace que se desperdicie espacio de almacenamiento y lo que es más importante: puede llevar a que se pierda la consistencia de los datos. Se produce una inconsistencia cuando copias de los mismos datos no coinciden.

  6. Dependencia de datos. Ya que la estructura física de los datos (la definición de los archivos y de los registros) se encuentra codificada en los programas de aplicación, cualquier cambio en dicha estructura es difícil de realizar. • El programador debe identificar todos los programas afectados por este cambio, modificarlos y volver los a probar, lo que cuesta mucho tiempo y está sujeto a que se produzcan errores. • A este problema, tan característico de los sistemas de archivos, se le denomina también falta de independencia de datos lógica-física.

  7. Consultas fijas y proliferación de programas de aplicación. Desde el punto de vista de los usuarios finales, los sistemas de archivos fueron un gran avance comparados a los sistemas manuales. • A consecuencia de esto, creció la necesidad de realizar distintos tipos de consultas de datos. • Sin embargo, los sistemas de archivos son muy dependientes del programador de aplicaciones: cualquier consulta o informe que se quiera realizar debe ser programado por él.

  8. 1.1.2. OBJETIVO DE LOS SISTEMAS DE BASE DE DATOS • Para trabajar de un modo más efectivo, surgieron las bases de datos y los sistemas de gestión de bases de datos (SGBD). • La base de datos es un gran almacén de datos que se define una sola vez y que se utiliza al mismo tiempo por muchos departamentos y usuarios. • En lugar de trabajar con archivos desconectados e información redundante, todos los datos se integran con una mínima cantidad de duplicidad. • La base de datos no pertenece a un departamento, se comparte por toda la organización. Además, la base de datos no sólo contiene los datos de la organización, también almacena una descripción de dichos datos. Esta descripción es lo que se denomina metadatos

  9. 1.1.3. MODELOS DE BASES DE DATOS • Para introducirnos en este tema, empezaremos definiendo que es un modelo. • Modelo: • Es una representación de la realidad que contiene las características generales de algo que se va a realizar. En base de datos, esta representación la elaboramos de forma gráfica.

  10. Modelo relacional • En este modelo todos los datos son almacenados en relaciones, y como cada relación es un conjunto de datos, el orden en el que éstos se almacenen no tiene relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar por un usuario no experto. La información puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la información.

  11. Modelo jerárquico • Un modelo de datos jerárquico es un modelo de datos en el cual los datos son organizados en una estructura parecida a un árbol. La estructura permite a la información que repite y usa relaciones padre/Hijo: cada padre puede tener muchos hijos pero cada hijo sólo tiene un padre. Todos los atributos de un registro específico son catalogados bajo un tipo de entidad.

  12. Ejemplo • Un ejemplo de un modelo de datos jerárquico sería si una organización tuviera los registros de empleados en una tabla (el tipo de entidad) llamada "Empleados". En la tabla habría atributos/columnas como el Nombre de pila, el Apellido, el Nombre de Trabajo y el Salario. La empresa también tiene datos sobre los hijos del empleado en una tabla separada "Hijos" llamada con atributos como el Nombre de pila, el Apellido, y la fecha de nacimiento. La tabla de Empleado representa un segmento paternal y la tabla de Hijos representa un segmento Infantil. Estos dos segmentos forman una jerarquía donde un empleado puede tener muchos hijos, pero cada hijo sólo puede tener un padre.

  13. Considere la estructura siguiente: En esta tabla, "el hijo" es el mismo tipo que "el padre". La jerarquía que declara EmpNo 10 es el jefe de 20, y30 y 40 cada informe a 20 es representado por la columna "Reporta". Llamada en la Base de datos relacional, la columna Reporta es una llave foránea, el referirse de la columna EmpNo. Si el tipo de datos "hijo" fuera diferente, estaría en una tabla diferente, pero todavía habría una llave foránea que se refiere la columna EmpNo de la tabla de empleados.

  14. Modelo orientado a objetos • En una base de datos orientada a objetos, la información se representa mediante objetos como los presentes en la programación orientada a objetos. Cuando se integra las características de una base de datos con las de un lenguaje de programación orientado a objetos, el resultado es un sistema gestor de base de datos orientada a objetos

  15. 1.2.- Análisis de requerimientos

  16. Para poder arribar con éxito a un buen diseño de Base de Datos es necesario hacer un detallado análisis de los requerimientos del sistema al cual nos enfrentamos. Pero qué implica exactamente este análisis?* Consiste en especificar lo que se requiere que haga el sistema o la aplicación. * Permite que las personas observen los elementos lógicos separados de los componentes físico. Después de lo cual se podrá desarrollar un modelo físico eficiente para la situación donde será utilizado.

  17. ¿Porque no analizamos requisitos al mismo tiempo que diseñamos e implementamos el sistema ?La respuesta es que el Diseño e Implementación son mucho más que el análisis (refinamiento y estructuración de los requisitos) por lo que se requiere una separación de intereses.– El Análisis: prepara y simplifica la siguiente actividad de diseño e implementación, delimitando los temas que deben resolverse y las decisiones que deben tomarse en esas actividades.– En el Diseño: debemos modelar el sistema y encontrar su forma incluyendo su arquitectura: una forma que de vida a todos los requisitos incorporados en el sistema.

  18. Es necesario recabar toda la información posible sobre la realidad, para luego analizarla con detenimiento, desde distintos puntos de vista con el fin de lograr diseñar un modelo que la represente de manera abstracta lo más fielmente posible.

  19. Debemos efectuarnos algunas preguntas con el fin de analizar nuestro sistema:¿Qué? ¿Quién? ¿Cuándo? ¿Cómo? ¿Dónde?Preguntas básicas y simples que nos permitirán luego realizar otras más puntuales:* ¿Cuáles son los objetos de datos primarios que va a procesar el sistema?* ¿Cuál es la composición de cada uno de estos objetos y qué atributos los describen?* ¿Cuál son las relaciones entre dichos objetos? * ¿Qué Procesos realiza nuestro sistema? ¿Cuándo se realizan? ¿Quién los hace?* ¿Qué intercambio de información existe dentro de los componentes del sistema? ¿Y con el exterior?* ¿Cuáles son los límites del sistema?* ¿Existen excepciones a tener en cuenta para la realización de los procesos?* ¿Cómo se almacena la información actualmente? ¿Qué datos se registran? ¿Quién lo hace?

  20. De allí surgirán:Entidades* Abstracciones de un objeto del mundo real. * Representación una colección de objetos que tienen propiedades comunes.* Ejemplo: CLIENTEAtributos* Propiedades de una entidad* Ejemplo: Nombre y apellido, edad, dirección, etc.Relaciones o Flujo de datos* Intercambio de información entre entidades * Representan datos en movimiento lógicamente relacionados.* Describen el movimiento de paquetes de datos de una parte del sistema a otra.

  21. Procesos* Una actividad, tarea, proceso, función, etc.* Transforma entradas en salidasAlmacenes* Colección de datos en reposo.* archivo en disco* datos en un fichero de papel* Ejemplo: una FACTURATerminadores o Entidades Externas.* Representan objetos con los cuales el sistema se comunica.* Personas, agrupamientos, organizaciones* otros sistemas de software o hardware* Se encuentran por fuera del sistema.

  22. El análisis de requerimientos solicita entendimiento, clasificación, organización, priorización y validación. En todo momento debemos considerar los límites del sistema, teniendo en claro cuál es su objetivo primario ¿Qué es lo que queremos que el sistema haga? ¿Qué salidas de información queremos obtener? Sólo de esta manera se podrá diferenciar qué de toda la información recolectada debemos almacenar y cómo deberá ser el diseño que se ajuste a ella.

More Related