Una base de datos(BD) es una colección de datos (que son hechos conocidos que tienen un resultado implícito) relacionados. Un conjunto de datos no relacionados no es una BD. Esta colección de datos esta en forma de archivos diseñados de tal manera para que sirvan a múltiples aplicaciones.
Presenta ciertas características:
· Representa algunos aspectos del mundo real.
· Es una colección coherente de datos con algún valor intrínseco, la relación entre estos datos es lógica (no es un conjunto aleatorio de datos).
· Se diseña, construye y completa con un propósito especifico y para ser usado por usuarios de cierta manera
· Está sustentado físicamente por archivos en memora no volátil.
Para diseñar una BD hay que definir los tipos de datos (int, str, real, char, etc), las estructuras (tablas) y restricciones (toda persona debe tener un nombre y apellido, largo y ancho no pueden ser números negativos, etc).
Para construir una BD hay que almacenar datos y estructuras concretas en un dispositivo de almacenamiento no volátil que lo gestiona un DBMS.
Para manipular una BD se realizan altas, bajas (no recomendable, poco común) y modificaciones y para extraer información se realizan consultas.
Un Data Base Management System(DBMS) es una colección de programas que permiten la construcción, definición, mantenimiento y actualización de una BD (no se utiliza para diseñar). Se usa para evitar la redundancia e inconsistencia de datos, garantizar que se pueda usar en todo momento, evitar problemas con la concurrencia, restringir acceso no autorizado, garantizar el almacenamiento persistente y la integridad de datos y generar backups. Se compone de dos tipos de lenguajes de consultas estructurados (SQL por Structured query language):
DDL (data definition language) es un conjunto de instrucciones que permite crear una BD ya que se utiliza para especificar el esquema de la misma. Se utiliza cuando se crea una BD y cuando se modifica su estructura.
DML (data manipulation language) es un conjunto de instrucciones que permite realizar altas, bajas, modificaciones y consultas. Dentro de este tipo de lenguaje hay dos tipos:
· Procedimentales: el usuario debe definir qué datos se muestran y cómo se accede a esos datos
· No-Procedimentales: el usuario debe definir qué datos se muestran sin especificar cómo se accede a esos datos
Actores involucrados en una BD:
· El analista de sistemas que determina los requerimientos y genera información que va a ser usada por el diseñador.
· El diseñador de BD que define la estructura que va a tomar la BD con la información que le da el analista y esa estructura se la da a los programadores.
· Los programadores que programan la BD con la estructura definida por el diseñador.
· El administrador de BD que se encarga de administrar el recurso en si. Esto puede conllevar programar backups, autorizar accesos, rehashear y es el responsable de problemas de seguridad y respuestas lentas.
· Los usuarios que son los que utilizan la BD. Puede ser que dentro de esta categoría haya varias sub categorías (ej: usuario alumno, profesor, no-docente)
Modelado de una BD
Para realizar un buen modelo para la base de datos, es necesario organizarlo en distintos niveles de abstracción. Estos son:
· En las vistas se ven solo los datos que le importa a un tipo de usuario. Hay muchas vistas para una BD.
· Modelo conceptual determina que datos se guardan y como se relacionan entre sí.
· Modelo físico muestra cómo se amacena realmente la información.
A la hora de modelar, se necesita elegir con qué modelo se va a crear la BD
· Modelo físico de datos: no sirve, viejo anticuado, siguiente…
· Modelo basado en registros (conceptual, físico): construye la BD sobre una computadora y se estructura en registros fijos. Tiene varios subtipos: redes dejo de existir en los 60, el jerárquico en los 80, el relaciona (aun siendo anticuado) es todavía utilizado y el OO es el más nuevo (pero no es el más arraigado por temas de performance).
· Modelo basado en registros (conceptual): es un modelo que facilita la presentación de la información a los usuarios al apuntar a un nivel de visión/conceptual, utilizando una estructura variable. También tiene subtipos: Entidad-Relación (el que usamos) es un poco anticuado en comparación con el OO pero se sigue utilizando ampliamente ya que sirve muy bien para especificar bases de datos y se comporta bien.
Modelo de diseño de datos
Sirve para hacer más fácil la comprensión de los datos a organizar y se utiliza ya que se puede ver la perspectiva de cada actor relacionado, ayuda a entender la naturaleza y la necesidad de cada dato y como cada actor utiliza cada dato. Importante destacar que no es lo mismo que el modelado de la BD. A la hora de construir estos modelos hay que separarlo en tres partes (para la práctica de esta catedra, las dos primeras son entidad-relación y la ultima es relacional):
· Conceptual: es un modelo superficial y genérico que se deriva de los requerimientos y exigencias del cliente. No se tiene que especificar qué modelo se utiliza ni que DBMS. Se necesita un contacto constante con el mismo a la hora de realizarlo. Se podría imaginar cómo hacer una maqueta de una casa.
· Lógico: es un modelo más detallado si se compara con el conceptual. Se tiene que especificar qué modelo se utiliza, pero no necesariamente de que DBMS. Se podría imaginar cómo hacer los planos de la casa.
· Físico: se genera utilizando el modelo lógico y con este se va a realizar la BD en el DBMS. Se debe elegir una DBMS que funcione con el modelo seleccionado en el lógico. Se podría imaginar cómo el maestro de obras construyendo la casa con el plano.
Modelo entidad-Relación
Fue propuesto por Chen en 1976 (nosotros vemos una variante de este modelo), cuando todavía se hablaba del modelo relacional y estaba en la cabeza de algunos diseñadores sin todavía estar definido. Para ese entonces, la forma en la que se diseñaban la base de datos era manual, y eso traía problemas tales como la repetición de datos y no había ningún tipo de estructura para la información (aunque era muy eficiente usarla, aun siendo puramente dado por la fuerza bruta). Fue ampliado por Codd en 1979 y fue un estándar en el 88. Se basa en ver al mundo real como un conjunto de objetos llamados entidades y las relaciones entre estos objetos. Este modelo permite visualizar el nivel conceptual y el lógico.
Sus objetivos son:
· Representar la información con un alto nivel de abstracción sin irnos a los detalles de cómo se resuelve el problema en el DBMS.
· Captar las necesidades del cliente (saber que nos dice que necesita, saber que necesita y como debe interactuar lo que necesita).
· Mejorar la interacción entre el cliente y el diseñador, haciendo que sea más fácil ver cuál es el problema real y como se podría plantear en el sistema.
Sus características son:
· Expresividad: tener todos los medios necesarios para describir un problema (en la catedra se usan 9 constructores).
· Formalidad: cada elemento tiene una representación precisa y bien definida (ej: rectángulo es entidad y rombo es relación).
· Minimalidad: cada elemento solo tiene una forma de entenderse (ej: rectángulo es entidad y rombo es relación).
· Simplicidad: el modelo es fácil de leer tanto para el cliente como para el desarrollador.
Los componentes del modelo de Chen, son abstractos y la base de toda BD hecha con el modelo ER:
· Entidad: representa un objeto del mundo real con identidad (se diferencia de los demás). En el modelo se agrupan muchas entidades que comparten características dentro de un conjunto de entidades (ej: auto1 es una entidad con matricula y con una marca, auto2 es otra entidad con matricula y con una marca, entonces si queremos poner estas entidades en una BD las agruparíamos en un conjunto de entidades llamado autos). Tanto entidades y conjunto de entidades, dentro de la catedra, AMBAS hacen referencia a conjunto de entidades.
· Relación: representan agregaciones entre 2 o más entidades (aunque en la catedra solo tomamos como correctas las relaciones binarias). Al igual que con las entidades, las relaciones se agrupan en conjunto de relaciones, que agrupan los conjuntos de relaciones que comparten características entre sí (igual que como pasaba con las entidades). Tanto relación y conjunto de r elaciones, dentro de la catedra, AMBAS hacen referencia a conjunto de relaciones. Las relaciones tienen una cardinalidadpor cada entidad que se relaciona y expresa si esa entidad es opcional o si es obligatoria (que se escribe con un “0” o un “1” respectivamente) y si esa entidad puede aparecer solo una vez o múltiples veces (que se escribe con un “1” o un “n” respectivamente). Las entidades pueden ser: binarias (una relación entre 2 conjuntos de entidades), ternarias (una relación entre 3 conjuntos de entidades), N-arias (una relación entre N conjuntos de entidades)o recursivas (una relación de unconjunto de entidades consigo mismo).
· Atributos: representa alguna característica básica de una entidad o una relación, y es lo mismo que el campo de un registro. Cada entidad tiene por lo menos un atributo. Los atributos tienen una cardinalidad que define si es opcional u obligatorio (que se escribe con un “0” o un “1” respectivamente) y que define si es monovalente o polivalente (que se escribe con un “1” o un “n” respectivamente). Para los atributos monovalentes obligatorios no hay que modelarlos explícitamente (agregándoles el 1.1) ya que si un atributo no tiene una cardinalidad visible se asume que es 1.1.
Want to print your doc? This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
DBD 1 Introducción y 2.1 Modelo ER