Bases de Datos - Resumen PDF

BASES DE DATOS ============== +-----------------------------------------------------------------------+ | Dato: hecho conocido con significado implícito que puede ser | | registrado. | |...

BASES DE DATOS ============== +-----------------------------------------------------------------------+ | Dato: hecho conocido con significado implícito que puede ser | | registrado. | | | | Base de datos: colección organizada de información (de datos | | estructurados) almacenados electrónicamente. Representa aspectos del | | mundo real, dirigida a usuarios, se diseña, crea y carga con datos | | para conseguir objetivos. Permite almacenar grandes volúmenes de | | datos y mantenerlos organizados y permite disponer de mecanismos que | | garanticen tanto la corrección de los datos como su seguridad. | | | | Esquema: conjunto de elementos de datos con nombre. | | | | Sistema Gestor de Bases de Datos (SGBD): conjunto de programas que | | permite definir, crear, manipular y controlar el acceso a la base de | | datos. | | | | Sistema de Bases de Datos (SBD): formado por la base de datos, el | | SGBD y los programas de aplicación. | | | | Metadatos: descripción de los datos (estructura, restricciones, | | creador, etc.). | | | | Sistema de Información (SI): colección de personas, procedimientos y | | equipos diseñados para recoger, procesar, almacenar, recuperar y | | visualizar información. La base de datos es un componente | | fundamental. | | | | - Componentes de un SI Automatizado: datos, software, hardware, | | administrador, procedimientos, usuarios. | +-----------------------------------------------------------------------+ Para construir un Sistema de Información es necesario analizar la funcionalidad y los datos del sistema, para después diseñar a través de modelos que facilitan su comprensión. Se diseña el software (Modelado de Procesos: funcionamiento del sistema) y la base de datos (Modelado de Datos: información con la que trabaja el sistema). Un modelo de datos es un conjunto de conceptos, reglas y convenciones que permiten describir y manipular datos. Permite representar y describir la información que maneja el SI, sus tipos de datos, restricciones y cómo están relacionados. Lo puede hacer desde tres niveles de abstracción: nivel conceptual (pensamiento), nivel lógico (en el ordenador) y nivel físico (en la unidad de almacenamiento). - Modelo de datos conceptual: crea el Esquema Conceptual, que describe los tipos de entidad y relación, los atributos y las restricciones. - Modelo de datos lógico: describe la estructura lógica global de la base de datos, por el Esquema Lógico. Incluye conceptos que el usuario final entiende y oculta detalles de almacenaje. El más usado es el Modelo Racional. - Modelo de datos físico: describe la estructura física global de la base de datos mediante el Esquema Interno, que especifica detalles de almacenamiento de los datos. El diseño de Bases de Datos consiste en diseñar la estructura lógica y física de los datos para satisfacer las necesidades de información de los usuarios en una organización, para un conjunto definido de aplicaciones. MÉTODO DE DISEÑO DE BASES DE DATOS: 1. Recopilación de requisitos de usuario 2. Diseño conceptual 3. Elección del SGBD 4. Diseño lógico 5. Diseño físico 6. Implementación ¿QUÉ ES EL DISEÑO CONCEPTUAL? Es el proceso de construir un modelo de los datos utilizados por una empresa u organización, independientemente de toda consideración física. Para ello, es necesario el análisis meticuloso del Catálogo de Requisitos de Datos del sistema. Incluye las siguientes fases: 1. Análisis de los requisitos de usuarios recogidos. 2. Diseño del Esquema Conceptual de datos. Esta etapa genera documentación: el Esquema Conceptual de la BD (diagrama Entidad-Relación) EL ESQUEMA CONCEPTUAL Se obtiene al analizar los requisitos de datos, mediante refinamiento y estructuración progresivos. Es un resumen de los requisitos de datos: una descripción "formal" de alto nivel de la base de datos. Debe ser diseñado sin considerar aspectos técnicos y/o de implementación como estos: usuarios, SGBD concreto, lenguajes de programación, programas de aplicación, plataformas hardware, restricciones de rendimiento, etc. MODELO ENTIDAD-RELACIÓN (MER) - Modelo de datos conceptual de alto nivel. - Permite describir el 'mundo real' como un conjunto de entidades y de relaciones entre ellas. - Gran difusión: - Muy extendido en los métodos de diseño de bases de datos (metodologías). - Soportado por herramientas software de diseño de bases de datos. ENTIDAD: cosa u objeto del mundo real con existencia propia y distinguible del resto, ya sea física o abstracta. - Tipo de entidad: define o representa un conjunto de entidades del mismo tipo. Una entidad, por tanto, es una instancia de un tipo de entidad. - Entidad débil: entre sus atributos no hay una clave, se identifica por su relación con una instancia de su entidad fuerte, relación identificador. La clave principal del tipo entidad débil será la concatenación de la clave primaria de la fuerte y un discriminante ATRIBUTO: característica de un tipo de entidad o relación. Una instancia particular es descrita por los valores de sus atributos. Todas las instancias de un mismo tipo de entidad tienen los mismos atributos (misma estructura). Pueden ser: +-----------------------------------+-----------------------------------+ | Simple: no divisible, atómico | Monovalorado: sólo un valor para | | | cada instancia | | Compuesto: se divide en otros con | | | significado propio | Multivalorado: más de un valor a | | | la vez en misma entidad | +===================================+===================================+ | Almacenado: su valor proviene del | Obligatorio | | mundo real | | | | Opcional: contendrán NULL | | Derivado: valor calculado a | | | partir de otra información | | +-----------------------------------+-----------------------------------+ - Nulo indica "ausencia de información": se desconoce el valor de un atributo. Tres significados: 1. El valor existe, pero falta (no se conoce) 2. No se sabe si el valor existe o no 3. La entidad concreta no tiene ningún valor aplicable para el atributo. - Atributo clave o identificador: atributo con valor distinto para cada instancia de un tipo de entidad. Identifica de forma única cada entidad concreta. - Clave compuesta: una clave puede estar formada por varios atributos. La concatenación de valores de dichos atributos es distinta para cada instancia. Debe ser mínima, no debe contener atributos redundantes, es decir, que puedan quitarse y el resto seguir formando una clave. - Clave principal: un tipo entidad puede tener más de una clave, hay que elegir una como identificador o clave principales (IP), el resto son claves alternativas (IA). RELACIÓN: asociación entre instancias de tipos de entidad. También se le llama interrelación e instancia de tipo de relación. - Tipo de relación: estructura genérica o abstracción del conjunto de relaciones existentes entre dos o más tipos de entidad. Grados: binaria (grado 2), ternaria (grado 3), cuaternaria (grado 4), recursiva/reflexiva, **n-aria**, etc. CARDINALIDAD: describe las posibles combinaciones de entidades que pueden participar en las relaciones. Son requisitos de datos que hay que incluir en el Esquema Conceptual. La restricción de participación indica el número mínimo de instancias de relación en las que puede participar una entidad, la cardinalidad indica el número máximo de instancias de relación (tuplas) en las que puede participar una entidad. Las cardinalidades mínimas indican cómo es la participación del tipo de entidad: obligatoria o total si es 1, opcional o parcial si es 0. JERARQUÍAS Caso especial de relación entre un tipo de entidad y varios otros tipos. La relación que se establece corresponde a la noción de 'es\_un\_tipo\_de'. Pueden formarse mediante un proceso de: - Especialización: de lo general a lo específico - Generalización: de lo específico a lo general Suelen estar definidos por una característica del supertipo. - Subtipos disjuntos: instancia del supertipo puede ser miembro de, como máximo, uno de los subtipos. PONER D - Subtipos solapados: instancia del supertipo puede ser miembro de más de un subtipo a la vez. PONER O - Especialización total: toda instancia del supertipo también debe ser instancia de algún tipo. DOBLE LÍNEA - Especialización parcial: instancia del supertipo puede no pertenecer a ninguno de los subtipos. LÍNEA SIMPLE Un subtipo hereda todos los atributos del supertipo, y todo tipo de relación en la que participa el supertipo. Un subtipo puede tener atributos propios específicos y participar en tipos de relación por separado. Un subtipo es un tipo de entidad completo cuando se considera sus atributos y tipos de relación específicos, más los atributos y tipos de relación heredados del supertipo. LENGUAJE DE MERCADO UNIFICADO (UML) Lenguaje de modelado ampliamente utilizado para modelar y documentar sistemas de información. Proporciona un vocabulario común (símbolos) y distintos tipos de vistas, diagramas y reglas, que permiten realizar todas las etapas de análisis y diseño de sistemas de información. Modelado de datos, diagrama de clases: ilustra las relaciones (vínculos, asociaciones) entre las clases que modelan el sistema. CLASE: tipo de entidad MER. Rectángulo con tres secciones: nombre, atributos y operaciones. Tipos: - Por defecto, un atributo se considera almacenado, monovalorado y obligatorio, igual que en el MER. - Si admite NULL se indica con \[0..máx.\], donde máx. ≥ 1. - Si es multivalorado se indica con etiqueta \[mín..máx.\], donde mín. es 0 o 1 y máx. \>1 puede ser n. - Si es derivado (calculado) se indica con la etiqueta \[derived\]. - Si es clave principal (o discriminante de una clase débil) se antepone PK. - Si es clave alternativa se antepone AK - No se puede representar atributos compuestos. ASOCIACIÓN: tipo de relación MER. La multiplicidad equivale a la cardinalidad notación min..max, un \* indica que no hay un límite máximo en la participación. Se indican "al revés" que en el MER. - Composición *identifying*: relación entre una clase débil y su clase fuerte. Se denota con una relación de composición: rombo negro junto a la clase fuerte. - Clase asociativa: permite representar atributos de relación. Amplía la descripción de una asociación entre dos clases porque tal vínculo tiene asociados atributos. - Relaciones n-arias: se representan en UML como una clase  GENERALIZACIÓN (JERARQUÍAS) Relación "...es un..." entre dos clases (subclase/superclase). La subclase hereda atributos y asociaciones de su superclase. Notación: flecha con la punta pegada a la superclase. **Sin cardinalidad**. MODELO RELACIONAL DE DATOS Introducido por Tedd Codd, de IBM Research, en 1970. Es un Modelo de Datos Lógico, basado en registros. Es el modelo más usado en las aplicaciones comerciales de procesamiento convencional de datos. Está dividido en estructura, integridad y manipulación de datos. Una relación está compuesta por: Esquema o Cabecera: conjunto de atributos (nombres de columna), no suele variar. Y, Estado, Cuerpo o Instancia: conjunto de tuplas de la relación. Propiedades de una relación: no existen tuplas repetidas, las tuplas y atributos no están ordenados, y los valores de atributos son atómicos. Las restricciones de integridad cumplen que forman parte de la Base de Datos, se satisfacen para cualquier estado, no varían con el tiempo y son específicas de cada Base de Datos particular (claves candidatas: primarias y alternativas, claves ajenas). Restricción de Integridad Referencial: el valor de una clave ajena debe coincidir con el valor de la clave primaria de alguna tupla de la relación referenciada, o bien es nulo. OBJETIVOS DEL DISEÑO LÓGICO - Transformar el esquema conceptual de datos en el esquema lógico de datos. En un conjunto de relaciones vinculadas. - Eliminar redundancias - Conseguir máxima simplicidad para lograr una estructura lógica adecuada para los datos y un equilibrio entre los requisitos de usuario y la eficiencia. FASES Y RESULTADO DEL DISEÑO LÓGICO La etapa de Diseño Lógico incluye dos fases: 1. Diseño lógico estándar 2. Diseño lógico específico Resultado: el Esquema Lógico específico, el cual está escrito en un lenguaje de programación ofrecido por un Sistema Gestos de Bases de Datos. Ejecutable en dicho SGBD además de la creación de las estructuras de datos (tablas) en la base de datos. A partir de ese momento, ya se puede introducir datos en el esquema, consultarlos, modificarlos, etc. 1. OBTENER RELACIONES (tablas) Crear relaciones para representar tipos de entidad, tipos de relación, y ciertos atributos del esquema conceptual de datos (o clases, asociaciones, etc. UML) 1. TIPO DE ENTIDAD FUERTE Se traduce a una relación (tabla) que incluye estos atributos: uno para cada atributo simple de la entidad y uno para cada componente de los atributos compuestos. Y clave primaria que se deriva del identificador principal y una clave alternativa (UNIQUE) por cada identificador alternativo. 2. TIPO ENTIDAD DÉBIL Se traduce a una relación (tabla) de igual modo que en el tipo de entidad fuerte. Puesto que la clave primaria del tipo de entidad débil se obtiene (total o parcialmente) de la de su tipo de entidad fuerte, NO puede ser definida hasta traducir el tipo de relación que la conecta a su fuerte. 3. TIPO DE RELACIÓN 1:N Se traduce a una clave ajena que referencia desde una relación a la otra. ¿En qué relación se introduce la clave ajena? Para saberlo, identificamos los tipos de entidad "padre" e "hijo" - Entidad padre: el que participa muchas veces en el tipo de relación. - Entidad hijo: el que participa solo una vez. La clave ajena servirá para enlazar cada tupla "hijo" con su correspondiente tupla "padre". Hay que añadir a la relación "hijo" una copia de la clave primaria de la relación "padre". Es la "propagación de la clave": el padre transmite su clave al hijo, donde es una clave ajena que referencia al padre. La clave ajena tendrá uno o varios atributos según tenga la clave primaria a la que referencia. - Si sólo es un atributo puede llamarse como la relación a la que referencia. - Pero cada atributo componente de la clave ajena puede tener el mismo nombre que la clave primaria de la que es copia, o puede llamarse de otra forma. Si el tipo de relación contiene atributos, añadirlos como atributos en la relación "hijo". La cardinalidad mínima 0 del tipo entidad "hijo" indica que la clave ajena SÍ admite nulo, y con ella, el resto de atributos del tipo de relación. La cardinalidad mínima 1 del tipo entidad "hijo" indica que la clave ajena NO admite nulo. La cardinalidad mínima 0 del tipo de entidad "padre" indica que puede haber tuplas en la relación "padre" no referenciadas mediante la clave ajena. - TIPO DE RELACIÓN 1:N IDENTIFICADOR Si el tipo de entidad "hijo" es débil, la clave ajena forma parte de la clave primaria. 4. TIPO DE RELACIÓN 1:1 Se traduce a una clave ajena. ¿En qué relación se incluye la clave ajena? Se decide con base en la participación de cada tipo de entidad. - Cardinalidad mínima 0 = participación opcional o parcial - Cardinalidad mínima 1 = participación obligatoria o total - PARTICIPACIÓN OBLIGATORIA EN UN LADO - Entidad padre: la de participación opcional. - Entidad hijo: la de participación obligatoria - Añadir la clave ajena en la relación correspondiente al tipo de entidad hijo. La cardinalidad máxima 1 de la relación "padre" hace que la clave ajena en la relación "hijo" también sea Clave Alternativa, esa es la diferencia con la traducción de las 1:N. - PARTICIPACIÓN OBLIGATORIA EN AMBOS LADOS La clave ajena se puede incluir en cualquiera de las dos relaciones. Aunque o habitual es que tenga más sentido que sea una concreta la que referencie a la otra. La Clave Ajena también es Clave Alternativa. - PARTICIPACIÓN OPCIONAL EN AMBOS LADOS Elegir los tipos de entidad "padre" e "hijo" e incluir la clave ajena en la hijo. La Clave Ajena en la relación "hijo" también es Clave Alternativa. 5. TIPO DE RELACIÓN M:N Crear una nueva relación. Añadir una copia de las claves primarias de los tipos de entidad conectados: serán las claves ajenas a cada una de las relaciones correspondientes a dichos tipos de entidad. Incluir atributos (columnas) para los atributos del tipo de relación. La clave primaria será la concatenación de ambas claves ajenas. Si la concatenación de ambas claves ajenas no forma una clave, significa que en el esquema conceptual se omitió un tipo de entidad conectado al tipo de relación. Es un error de diseño que puede ser subsanado ahora, añadir alguno de los atributos de la relación para conseguir una clave. 6. TIPO DE RELACIÓN N-ARIA Crear una nueva relación: incluir atributos (columnas) para los atributos del tipo de relación, añadir una copia de las claves primarias de los tipos de entidad conectados (serán claves ajenas a cada uno de ellos), la clave primaria de la nueva relación será una de estas: concatenación de las claves ajenas, combinación de algunas claves ajenas, concatenación de varias claves ajenas y algún atributo para subsanar un error de diseño. Las claves ajenas serán cada una de las entidades relacionada separadas. A veces, la clave primaria puede reducirse: la cardinalidad máxima de una entidad en otra es 1, lo que identifica que la participación única de una entidad puede ser clave primaria de la relación completa. 7. ATRIBUTO MULTIVALORADO Crear una nueva tabla: incluir un atributo (columna) con el mismo nombre que el atributo multivalorado, añadir una copia de la clave primaria del tipo de entidad a la que está conectado será una clave ajena, la clave primaria será la concatenación de la clave ajena y el atributo o el atributo solo. 2. COMPROBAR LAS RESTRICCIONES DE INTEGRIDAD Documentar las restricciones de integridad necesarias para impedir que la base de datos pueda llegar a estar incompleta, imprecisa o incoherente. Evitar la pérdida de semántica inherente al proceso de traducción del Esquema Conceptual en el Esquema Lógico. 1. DATOS REQUERIDOS - Algunos atributos deben siempre contener un valor válido (no nulo) - Comprobar que los atributos (de tipos de entidad) que no admiten NULL se han traducido correctamente a atributos de relaciones (columnas de tablas) que no admiten NULL. - Ídem para los que sí lo admiten. - SQL: restricciones NOT NULL. 2. RESTRICCIONES DE DOMINIO DE ATRIBUTOS Todo atributo tiene un dominio o conjunto de valores legales: - Para algunos de estos atributos pueden existir restricciones que afectan a sus valores legales. - Estas restricciones pudieron ser identificadas en el Diseño Conceptual. - Ahora deben expresarse en el Esquema Lógico de datos. - Indicar estas restricciones en el campo "Comprobación" de las plantillas correspondientes. - Una restricción de comprobación debe ser cierta PARA CADA TUPLA de la relación. - SQL: restricciones de tipos de datos y de tipo CHECK. 3. INTEGRIDAD DE ENTIDAD - Comprobar que ninguna clave primaria de cualquier relación (tabla) puede contener nulo - SQL: restricción PRIMARY KEY, los atributos (columnas) componentes de cada clave primaria deben se definidas como NOT NULL. - Comprobar si las claves alternativas pueden o no tener nulo. - SQL: UNIQUE con la restricción NULL o NOT NULL que corresponda. 4. INTEGRIDAD REFERENCIAL - Comprobar que cada clave ajena está bien definida: asegurarse de que tiene tantos atributos como clave primaria a la que referencia. Una clave primaria compuesta por varios atributos debe referenciarse desde una clave ajena compuesta por el mismo número de atributos. - Confirmar que está bien indicado si puede o no admitir nulo. Con base en la cardinalidad mínima del tipo de entidad hijo en la relación de la que proviene la clave ajena. - SQL: restricción FOREIGN KEY. DISEÑO LÓGICO ESPECÍFICO: ESPECIFICACIÓN DEL ESQUEMA LÓGICO EN UN SGBD REAL Ya tenemos el Esquema Lógico definido en el Modelo Relacional y hemos elegido el SGBD para la implementación. Hay que analizar: - ¿Soporta el Modelo de Datos Relacional? ¿Hasta qué punto? ¿Cómo escribir el Esquema Lógico con la sintaxis propia del modelo de datos particular del SGBD comercial elegido? ¿Ofrece un dialecto SQL? ¿Tiene un asistente para crear tablas, etc.? Estudiar la correspondencia entre conceptos del Modelo de Datos Relacional y los del lenguaje de SGBD: 1. Soporte total: el SGBD soporta el Modelo Relacional sin restricción. Transformación casi directa al SQL propio del SGBD. 2. Soporte parcial: el SGBD no soporta algunos conceptos, o sí lo hace, pero con limitaciones. EL LENGUAJE RELACIONAL SQL Structured Query Language (lenguaje estructurado de consulta) Primer lenguaje de Bases de Datos de alto nivel. Años 70. Diseñado e implementado en el IBM's Research Laboratoy (San José, California), para el SGBD Relacional experimental "System R". Definición de un lenguaje estándar para SGBDR. ANSI (American National Standards Institute) + ISO (International Standardization Organization) - SQL-86, extendido en 1989 (SQL-89) - SQL-92 - Versiones (extensiones) posteriores - SQL:1999 (características de Orientación a Objetos, disparadores,...) - SQL:2003 (incluye XML...) - SQL:2006, SQL:2008, SQL:2011, SQL:2016 (actual) y SQL-2019 (en borrador) Primeras implementaciones en 1979: ORACLE y poco después INGRES. Lenguaje de BD completo (no solo de consulta), los comandos están organizados en: - Lenguaje de Definición de Datos (LDD): para crear, modificar y eliminar estructuras de datos - Instrucciones CREATE, ALTER, DROP. - Lenguaje de Manipulación de Datos (LMD): para introducir datos en tablas, actualizarlas y eliminarlos o extraer - Órdenes INSERT, UPDATE, DELETE. Sentencia SELECT. 1. CREACIÓN DE TABLAS - Sentencia CREATE TABLE, define una tabla: nombre, columnas y restricciones. - Nombre único dentro del esquema. - Para cada columna se puede indicar: nombre, tipos de datos y restricciones. - Restricciones de tabla: clave candidata, clave ajena y restricciones de otro tipo. - Ordenamiento de columnas y filas: una vez creada la tabla, las columnas y filas quedan en el orden de inserción. - Las tablas creadas con CREATE TABLE son denominadas tablas base: el SGBD las almacena físicamente. 2. DEFINIR COLUMNAS DE TABLA - En la sentencia CREATE TABLE cada columna se define en una línea, la definición termina con una coma. - Hay que especificar el nombre de la columna, los tipos de datos y restricciones de columna. - TIPOS DE DATOS DE COLUMNA SQL-92 - Numéricos: - Enteros y reales - INTEGER (también INT), SMALLINT - REAL (simple precisión), DOUBLE PRECISION, FLOAT (p) - Con formato - NUMERIC (p,e) o DECIMAL (p,e) (también DEC(p,e)) P: precisión, número total de dígitos del número E: escala, cuántos dígitos de los p totales son decimales, el valor por omisión de e = 0. - Cadena de caracteres: - Longitud fija: CHAR(n) n: nº de caracteres; por omisión n=1 - Longitud variable: VARCHAR(n) n: máximo nº de caracteres - Temporales: - DATE (10 posiciones) = YEAR; MONTH, DAY (yyy-mm-dd) - TIME (8 posiciones) = HOUR, MINUTE, SECOND (hh:mi:ss) - TIMESTAMP (marca de tiempo): incluye DATE, TIME, fracciones de segundo. Y, si se incluye WITH TIME ZONE, incluye desplazamiento respecto al UTC (tiempo universal coordinado) 3. DEFINIR RESTRICCIONES DE COLUMNA Además del nombre y del tipo de datos, la definición de una columna puede incluir restricciones de integridad aque afectan a los valores de esa columna. - NULL o NOT NULL: indica si la columna puede contener nulo o no, por omisión se asume que es NULL - PRIMAREY KEY (lista\_columnas): columnas que componen la clave primaria (PK), ningún componente de la PK puede contener NULL. En SQL estándar ANSI, se asume NOT NULL por omisión para cada columna componente de la PK, sin embargo, MySQL obliga a definirla. Un CREATE TABLE debe incluir una y sólo una PK. - UNIQUE (lista\_columnas): columnas que forman una clave alternativa. Sí se permite que contenga NULL. - FOREIGN KEY (lista\_columnas) REFERENCES tabla(lista\_columnas): definición de la clave ajena. Asegura la Integridad Referencial (los valores de las columnas clave ajena deben existir en la columna clave primaria a la que hacen referencia). Cada clave ajena debe estar formada por tantas columnas como tenga la clave primaria a la que referencia. Cada columna de la clave ajena debe tener el mismo tipo de datos que la columna correspondiente de la clave primaria a la que referencia. - CONSTRAINT nombre\_RI: da nombre a una restricción de integridad en SQL-92 y en SQL de MySQL es opcional. - CHECK (expresión): permite definir una condición sobre los valores de ciertas columnas que debe cumplir toda fila de la tabla. Se puede colocar como parte de la definición de una columna, para permitir sólo ciertos valores. Dependiendo de la versión del SGBD MySQL instalado, es posible darle nombre y/o colocarla por separado, fuera de la definición de las columnas. DATOS LÓGICOS O BOOLEANOS Aquel que puede representar dos valores: TRUE o FALSE. Estos valores se generan aplicando operadores de comparación u operadores lógicos a otros valores de otros tipos de datos. - Operadores de comparación: \>, \=, \