TECNOLOGÍAS DE LA INFORMACIÓN EN LINEA BASE DE DATOS 4 créditos Docente autor: Docente tutor: Dra. Lucía Rivadeneira Barreiro MsC. Cristhian Cedeño Sarmiento Mg. Victor Martínez Falcones Titulaciones • Semestre Cuarto Base de datos Tutorías: El profesor asignado se publicará en el entorno virtual de aprendizaje online.utm.edu.ec), y sus horarios de conferencias se indicarán en la sección CAFETERÍA VIRTUAL. Periodo mayo - septiembre 2022 Índice Tabla de contenido Tema 1: Modelado de datos y modelo de datos.................................................................... 3 1.1 La importancia de los modelos de datos ......................................................................... 3 1.2 Lo básico de los modelos de datos .................................................................................. 4 1.3 Las reglas de negocio o requerimientos de automatización ............................................ 8 1.4 La evolución de los modelos de datos........................................................................... 10 Tema 2: Tipos de modelos de datos ..................................................................................... 11 2.1 Modelo de datos jerárquico: Características básicas ..................................................... 11 2.2 Modelo de datos de red: Características básicas ........................................................... 14 2.3 Modelo de datos relacional: Características básicas ..................................................... 16 Tema 3: Fases de diseño ....................................................................................................... 19 3.1 Niveles de abstracción: conceptual, lógico y físico ...................................................... 19 3.2 Modelo entidad-relación ............................................................................................... 23 3.3 Entidad: fuerte, débil; supertipo, subtipo ...................................................................... 25 3.4 Atributos: simples, compuestos; monovalentes, multivalentes; derivados ................... 29 3.5 Identificadores: internos, externos, mixtos; simples y compuestos .............................. 29 3.6 Grado de una relación: unaria, binaria, ternaria, n-aria ................................................. 33 3.7 Cardinalidad de correspondencia de clases ................................................................... 36 3.8 Cardinalidad de cobertura de clases .............................................................................. 40 Tema 4: Esquema conceptual y lógico ................................................................................ 42 4.1 Esquema conceptual: de alto nivel, detallado ............................................................... 43 4.2 Relaciones redundantes ................................................................................................. 44 4.3 Transformación de relaciones M:N ............................................................................... 45 4.4 Esquema lógico de datos ............................................................................................... 46 4.5 Pautas para transformar un esquema conceptual a un esquema lógico relacional ........ 48 4.6 Modelo relacional. Tablas y sus características: Filas, columnas ................................. 52 4.7 Claves: Clave candidata, superclave, clave primaria, clave foránea ............................. 52 4.8 Reglas de Codd ............................................................................................................. 54 4.9 Diccionario de datos. Tipos de datos. Instancia de base de datos ................................. 56 1 Organización de la lectura para el estudiante por semana del compendio Semanas Compendio Semana 4 Páginas 3 – 11 Semana 5 Páginas 11 – 18 Semana 6 Páginas 19 – 29 Semana 7 Páginas 29 – 41 Semana 8 Páginas 42 – 48 Semana 9 Páginas 48 - 58 2 Unidad 2. Diseño y modelo de datos Resultado de aprendizaje: Construir sistemas de bases de datos relacionales y gestionar sus datos: ingreso, actualización, eliminación y extracción, mediante el lenguaje de consulta estructurado. Tema 1: Modelado de datos y modelo de datos El modelado de datos es el proceso de crear un modelo de datos para que los datos se almacenen en una base de datos. Es decir, el modelado de datos es el proceso de describir estructuras de información y ayuda en la representación visual de los datos y hace cumplir las reglas de negocios, el cumplimiento normativo y las políticas gubernamentales sobre los datos (Beynon-Davies, 2018). Tiene como finalidad simbolizar una parte del mundo real para almacenarla en una base de datos (Sánchez, 2004). Los modelos de datos garantizan la coherencia en las convenciones de nomenclatura, los valores predeterminados, la semántica y la seguridad, al tiempo que garantizan la calidad de los datos y es el primer paso en el diseño de la base de datos. El modelo de datos se define como un modelo abstracto que organiza la descripción de los datos, la semántica de los datos y las restricciones de coherencia de los datos (Elmasri et al., 2002). El modelo de datos enfatiza qué datos se necesitan y cómo deben organizarse en lugar de qué operaciones se realizarán con los datos y se lo puede expresar como el plan de construcción de un arquitecto, que ayuda a construir modelos conceptuales y establecer una relación entre los elementos de datos. Un tipo de técnica de modelado de datos es el modelo entidad-relación (ER) que se abarcará más adelante. 1.1 La importancia de los modelos de datos El modelo de datos se puede referir a un modelo abstracto que organiza elementos de datos y estandariza cómo se relacionan entre sí y con las propiedades de las entidades del mundo real (Ordoñez et al., 2016). Un modelo de datos determina explícitamente la estructura de los datos y facilita la interacción del diseñador de la base de datos, la persona que programa las aplicaciones y los usuarios finales y permiten entender la interacción de los datos dentro de una organización. La aplicación de modelos de datos es importante dentro de una organización por las siguientes razones: 3 • Asegura que todos los objetos de datos requeridos por la base de datos estén representados con precisión. La omisión de datos dará lugar a la creación de informes defectuosos y producirá resultados incorrectos. • Un modelo de datos ayuda a diseñar la base de datos en los niveles conceptual, físico y lógico. • La estructura del modelo de datos ayuda a definir las tablas relacionales, las claves primarias y externas y los procedimientos almacenados. • Proporciona una imagen clara de los datos base y los desarrolladores de bases de datos pueden utilizarla para crear una base de datos física. • También es útil identificar datos faltantes y redundantes. • Facilita la comunicación y organiza los datos de los usuarios. • Aunque la creación inicial del modelo de datos requiere mucho tiempo y trabajo, a largo plazo, hace que la actualización y el mantenimiento de su infraestructura de TI sean más baratos y rápidos. Video: En el siguiente enlace podrán profundizar un poco más sobre el modelo de datos: https://www.youtube.com/watch?v=4qFZ-5i4GS8 1.2 Lo básico de los modelos de datos Los modelos de datos funcionan como una abstracción simplificada de la realidad. En un hospital, cada paciente es diferente y debe tratarse de forma individual. En software, sin embargo, hablamos de un paciente abstracto. Lo mismo se aplica a los restaurantes y cualquier otro ámbito. Cada vez, debe tomar decisiones sobre qué información es importante y debe incluirse en el modelo de datos y qué omitir. En un hospital, debe conocer la edad del paciente. Pero la edad de la misma persona no tendrá mucha importancia en un restaurante. En aplicaciones complejas, a menudo es necesario responder a cientos de preguntas antes de escribir una sola línea de código. Entonces, ¿cómo se ve un modelo de datos, en realidad? Por lo general, se crea en forma gráfica. Hay que crear un diagrama que identifique los principales conceptos del dominio, sus características y relaciones. Los conceptos suelen adoptar la forma de rectángulos con nombre. En el caso de un hospital, podrían nombrarse: paciente, médico, sala, etc. Las relaciones entre ellos se ilustran como líneas o flechas que conectan los rectángulos. 4 Los rectángulos se pueden anotar de varias formas para mostrar información adicional. Por ejemplo, podría enumerar toda la información necesaria para un paciente: nombre, edad, sexo, etc. Clasificación de los modelos de datos Figura 1. Clasificación de los modelos de datos. Fuente: Sánchez (2004) Los elementos del esquema presentado en la Figura 1 son: • Mundo real: Contiene la información tal cual la percibimos como seres humanos. Es el punto de partida • Esquema conceptual: Representa el modelo de datos de forma independiente del SGBD que se utilizará • Esquema canónico (o de base de datos): Representa los datos en un formato más cercano al del ordenador • Esquema interno: Representa los datos según el modelo concreto de un sistema gestor de bases de datos. Por ejemplo, Oracle • Base de datos física: Los datos tal cual son almacenados en disco. Conceptos fundamentales usados en el modelo de datos Existen conceptos generales que están asociados al modelo de datos: • Entidad: Es un objeto específico que existe en el mundo real. Por ejemplo, una oficina, departamento, empleado, computadora, cliente o producto. Las entidades deben tener claves para poder relacionarse con otras entidades. 5 • Relación: Son los vínculos entre entidades. Por ejemplo, una relación entre la entidad Empleado y la entidad Departamento puede ser que un empleado sea miembro de un departamento. En una relación uno a uno (1:1 o 1..1), cada instancia de una entidad se relaciona con una instancia de una segunda entidad. En una relación de uno a muchos (1:M o 1..*), cada instancia de una entidad se relaciona con una o más instancias de una segunda entidad. En una relación de muchos a muchos (M:N o *..*), muchas instancias de una entidad se relacionan con muchas instancias de la otra entidad. • Atributo: Es una propiedad o característica propiedad de una entidad o relación. Por ejemplo, la entidad Empleado puede tener los atributos de nombre, dirección particular, número de teléfono particular y fecha de contratación. • Restricción: Son las reglas que obligan a los SGDB a verificar que los datos satisfagan la semántica establecida. Las restricciones se utilizan para limitar el tipo de datos que pueden incluirse en una tabla. Esto asegura la precisión y confiabilidad de los datos en la tabla. Si hay alguna violación entre la restricción y la acción de datos, la acción se cancela. Las restricciones pueden ser de nivel de columna o de tabla. • Dominio: Es un objeto definido que contiene metadatos del modelo de datos. Es decir, datos sobre datos, como tipos de datos, reglas de validación, dependencias o valores predeterminados que agrupa datos y el comportamiento requerido para su funcionamiento • Diccionario de datos: Es un conjunto de metadatos. Cuando el modelo de datos se implementa en un SGBD, el diccionario de datos se convierte en un conjunto de tablas y vistas de solo lectura. Es importante recalcar que los nombres que se les otorguen a las entidades, atributos o relaciones tienen que describir los objetos a los que se refiere, usando terminología que sea familiar a los usuarios. Por ejemplo, si una entidad es referente a un estudiante, esta se debería llamar Estudiante o Alumno. De esta forma, se facilita la comunicación entre diferentes usuarios que intervienen en el modelo de datos. Ventajas y desventajas del modelo de datos Entre las ventajas de implementar el modelo de datos encontramos: • El objetivo principal del diseño de un modelo de datos es asegurarse de que los objetos de datos ofrecidos por el equipo funcional se representen con precisión. 6 • El modelo de datos debe ser lo suficientemente detallado para ser utilizado para construir la base de datos física. • La información del modelo de datos se puede utilizar para definir la relación entre tablas, claves primarias y externas y procedimientos almacenados. • El modelo de datos ayuda a las empresas a comunicarse dentro y entre organizaciones. • El modelo de datos ayuda a reconocer las fuentes correctas de datos para poblar el modelo. Con respecto a las desventajas se nombran las siguientes: • Para desarrollar el modelo de datos, se deben conocer las características físicas de los datos almacenados. • Incluso los cambios más pequeños realizados en la estructura requieren modificaciones en toda la aplicación. • No hay un lenguaje de manipulación de datos establecido en SGBD. Propiedades de los datos Para proceder con el modelo de datos, hay que considerar algunas propiedades importantes de los datos y su calidad, mismos que deben cumplir los siguientes requisitos para asegurar un buen desempeño del modelo: • Propiedades relacionadas con la definición: o Relevancia: La utilidad de los datos en el contexto del negocio o Consistencia: La compatibilidad del mismo tipo de datos de diferentes fuentes • Propiedades relacionadas con el contenido: o Puntualidad: La disponibilidad de datos en el momento requerido y qué tan actualizados están los datos o Precisión: Qué tan cerca de la verdad están los datos • Propiedades relacionadas tanto con la definición como con el contenido: o Integridad: Cuántos de los datos requeridos están disponibles o Accesibilidad: dónde, cómo y para quién están disponibles o no los datos o Costo: El costo incurrido para obtener los datos y ponerlos a disposición para su uso 7 Figura 2. Propiedades de calidad de los datos en el modelo de datos. 1.3 Las reglas de negocio o requerimientos de automatización Las reglas de negocios son una parte fundamental del modelo de datos. La regla de negocio es una descripción breve, precisa e inequívoca de una política, procedimiento o principio dentro del modelo de datos y es importante porque prepara el escenario para la identificación adecuada de entidades, atributos, relaciones y restricciones (Pereira Toledo et al., 2020). Las reglas de negocio están dirigidas a especificar qué restricciones o condiciones deben cumplirse para que un dato se considere válido en una base de datos (Boggiano-Castillo et al., 2013). También se la puede definir como una declaración que impone algún tipo de restricción sobre un aspecto específico de la base de datos, como los elementos dentro de una especificación de campo para un campo en particular o las características de una relación determinada. Una regla de negocio se basa en la forma en que la organización percibe y utiliza sus datos, que se determina a partir de la forma en que la organización funciona o realiza sus negocios. En las reglas del negocio, generalmente los sustantivos se usan para describir entidades (i.e., estudiantes, clases) y los verbos para las relaciones entre las entidades (i.e., los estudiantes pueden tomar una clase). Las relaciones pueden ser uni o bidireccionales como se explicó en los conceptos fundamentales de modelo de datos. Es decir, un estudiante que repite 8 por tercera ocasión debe tomar una sola clase (1:1), o un estudiante de 4to semestre debe tomar 4 clases (1:M) Para identificar las reglas de negocios, se pueden identificar y obtener de diferentes fuentes como los gerentes, los tomadores de decisiones, jefes departamentales, documentos escritos o entrevistas directas con usuarios finales para determinar como usan los sistemas y cuáles son los requerimientos y retos a los que se enfrentan cuando usan las aplicaciones. Las razones para identificar y documentar las reglas de negocios dentro de una organización son para: • Estandarizar la visión de los datos de la organización • Facilitar la comunicación entre usuarios y diseñadores • Asistir a los diseñadores a entender la naturaleza, rol, alcance de los datos y los procesos de la organización • Desarrollar reglas apropiadas para la relación de entidades y restricciones • Crear un modelo de datos preciso y confiable Por ejemplo, una regla de negocio es que una persona puede tener varios vehículos y cada uno de esos vehículos tiene que pertenecer a una persona. Otra puede ser que no se permita emitir una factura a un cliente inexistente o controlar que el saldo negativo de una cuenta bancaria no sobrepase una cantidad determinada. Implementación de las reglas del negocio • Reglas de modelo de datos (constraints): Son aquellas reglas que se encargan de controlar que la información almacenada para cada atributo o propiedad es válida. Por ejemplo, no hay precios negativos de productos. • Reglas de restricción (rules): Restringen los datos que el sistema puede contener. Es decir, su función principal es garantizar que el dato insertado o modificado cumpla con cierta condición. Por ejemplo, en la columna teléfono sólo puede ingresarse datos numéricos. • Reglas de relación (foreign keys): Controlan las relaciones entre los datos. Por ejemplo, todo pedido debe ser realizado por un cliente, quien debe estar en estado activo en la base de datos. Además, una vez que el cliente ha hecho un pedido no se lo puede eliminar, a menos que previamente se eliminen sus otros pedidos. 9 • Reglas de flujo (store procedures): Indican qué camino recorre la información y obliga a qué sólo se siga ese camino. • Reglas de derivación (views): Especifican y controlan la obtención de información. Por ejemplo, el total de un pedido se puede derivar de los distintos productos que lo componen. Mientras que el total de cada producto se calcula por el número de unidades del producto vendido y el precio por unidad. Video: En el siguiente enlace pueden reforzar sus conocimientos de las reglas de negocios https://www.youtube.com/watch?v=mb6ezioTpIc 1.4 La evolución de los modelos de datos Los modelos de datos definen cómo se modela la estructura lógica de una base de datos y son entidades fundamentales para introducir la abstracción en un SGBD. Los modelos de datos definen cómo se conectan los datos entre sí y cómo se procesan y almacenan dentro del sistema. El primer modelo de datos podría ser modelos de datos planos, donde todos los datos utilizados debían mantenerse en el mismo plano. Los modelos de datos anteriores no eran tan científicos, por lo que eran propensos a introducir muchas anomalías de duplicación y actualización. Sin embargo, los modelos de datos planos no califican estrictamente como un modelo de datos ya que consta de una matriz bidimensional única de elementos de datos, en la que se supone que todos los miembros de una columna determinada tienen valores similares y que todos los miembros de una fila están relacionados entre sí. En la década de 1960 se crearon los modelos jerárquicos y de redes. El modelo jerárquico presentaba cierto grado de dificultad para representar relaciones M:N. En estos modelos, se evidenció la dependencia estructural de los datos y no se podían realizar consultas ad hoc. A inicios de los 70 aparece el modelo relacional, que presentó un modelo conceptual más sencillo y que demostraba independencia estructural. Si permite las consultas ad hoc a través del lenguaje SQL. En 1976 surge el modelo relacional que es mucho más fácil de entender por su aspecto semántico, pero estaba limitado al modelo de datos conceptual. 10 Posteriormente, hasta 1990 se desarrollaron modelos semánticos, en donde surgen modelos orientados a objetos y los SGBDR, los cuales dan soporte a objetos complejos, permite el uso de datos sin estructura y permite la jerarquía de clases. Finalmente, durante la última década han surgido modelos No SQL que se enfocan en el meta datos (big data). Estos modelos presentan menos dependencia a la parte semántica y es aprovechado cuando se trata de enormes cantidades de datos. Tema 2: Tipos de modelos de datos Un modelo de base de datos es una especificación que describe cómo se estructura y se utiliza una base de datos. Es decir, un tipo determinado de modelo de base de datos define el diseño lógico y la estructura de una base de datos y define cómo se almacenarán, accederán y actualizarán los datos en un sistema de gestión de bases de datos. Se han sugerido varios de estos modelos y los más comunes incluyen el modelo de datos jerárquico, de red y relacional. 2.1 Modelo de datos jerárquico: Características básicas Este modelo de datos organiza los datos en una estructura en forma de un árbol invertido, con una única raíz, a la que están vinculados todos los demás datos (Sánchez Romero & Villacis Miranda, 2020). La jerarquía comienza con los datos raíz (o nodo raíz que es el nivelo 0) y se expande como un árbol, agregando nodos secundarios a los nodos principales. El modelo de base de datos jerárquico exige que cada nodo secundario tenga solo un padre, mientras que cada registro principal puede tener uno o más registros secundarios. Los nodos que no tienen hijos se denominan hojas y la altura representa el número de niveles de la estructura jerárquica. Uno de los principales objetivos de las bases de datos jerárquicas es gestionar grandes volúmenes de datos. Concepto y esquema El concepto del modelo de datos jerárquico se basa en la representación de las situaciones de la vida real en las que predominan las relaciones tipo uno a muchos (1:M). Su esquema se organiza en niveles múltiples en función de una estricta relación padre-hijo, de tal modo que un padre puede tener más de un hijo, todos ellos localizados en el mismo nivel, pero un hijo sólo puede tener un padre situado en el nivel inmediatamente superior al suyo. Las entidades en este modelo se denominan segmentos (nodos) y los atributos campos. Los segmentos se organizan en niveles, así en un mismo nivel estarían todos los segmentos que dependen de un segmento del nivel inmediatamente superior. Este modelo describe de 11 manera eficiente muchas relaciones del mundo real, como el índice de un libro. La relación puede ser de uno a muchos (1:M) entre dos tipos diferentes de datos, por ejemplo, un departamento puede tener muchos cursos, muchos profesores y, por supuesto, muchos estudiantes. Para recuperar datos de un modelo de datos jerárquico, es necesario recorrer todo el árbol comenzando desde el nodo raíz. Este modelo es reconocido como el primer modelo de base de datos creado por IBM en la década de 1960. Ejemplo1: En una universidad se implementa un modelo de datos jerárquico para almacenar información de docentes y estudiantes. Así, el nodo raíz es la coordinadora académica, quien es el nodo padre del coordinador de computación. Este, a su vez es el nodo padre de los profesores, quienes tienen múltiples hijos (alumnos). Figura 3. Representación de un modelo de datos jerárquico. La altura del modelo es de 4 Características principales Las características principales de implementar este modelo son: • Globalización de la información: Permite a los diferentes usuarios considerar la información como un recurso corporativo que carece de dueños específicos. 1 https://sites.google.com/site/fsisbdd/home/base-de-datos-jerarquica 12 • Eliminación de información inconsistente: Si existen dos o más archivos con la misma información, los cambios que se hagan a éstos deberán hacerse a todas las copias del archivo de facturas. • Permite compartir información. • Independencia de datos: el concepto de independencia de datos es quizás el que más ha ayudado a la rápida proliferación del desarrollo de este tipo de modelo de datos. En este tipo de modelos se establece en forma de árbol donde la raíz es un nodo ficticio. Así tenemos que, una base de datos jerárquicas es una colección de árboles. Ventajas El modelo de base de datos jerárquico ofrece las siguientes ventajas: • El modelo permite agregar y eliminar información nueva fácilmente. • Se puede acceder rápidamente a los datos de la parte superior de la jerarquía. • Este modelo funciona bien con medios de almacenamiento de datos lineales como cintas. • Es compatible con sistemas que funcionan a través de una relación de uno a muchos. Por ejemplo, la estructura orgánica funcional en una empresa, representada mediante un organigrama. Hay un presidente con muchos gerentes debajo de ellos, y esos gerentes tienen muchos empleados debajo de ellos, pero cada empleado tiene solo un gerente. Desventajas Si bien el modelo jerárquico es adecuado para estructuras simples, solo admite relaciones de uno a muchos (1:M). Esto significa que cada nodo hijo solo puede tener un padre. Si, por ejemplo, la base de datos contiene los nombres de ambos padres y sus hijos que trabajan para una empresa, no puede describir el hecho de que ambos padres de cada hijo trabajaban para esa empresa. En el lenguaje de las bases de datos, esto sería una relación de "muchos a uno" (o "muchos a muchos" si hay más de un hijo involucrado) y las bases de datos jerárquicas no las describen bien. Otras desventajas incluyen: • Requiere que los datos se almacenen repetidamente en muchas entidades diferentes debido a la estructura en forma de árbol. • Necesita una búsqueda secuencial, lo que significa que el sistema de administración de la base de datos tiene que recorrer todo el modelo de arriba a abajo hasta que se 13 encuentre la información requerida. Esto hace que las consultas sean lentas cuando hay bastantes datos. 2.2 Modelo de datos de red: Características básicas El modelo de red es la extensión de la estructura jerárquica porque permite que las relaciones de muchos a muchos se gestionen en una estructura en forma de árbol que permite múltiples padres. Una característica única del modelo de red es su esquema, que se ve como un gráfico donde los tipos de relación son arcos y los tipos de objeto son nodos (Castillo Arrojo, 2018). A diferencia de otros modelos de bases de datos, el esquema del modelo de red no se limita a ser un entramado o una jerarquía; el árbol jerárquico se reemplaza por un gráfico, que permite conexiones más básicas con los nodos. Hay dos conceptos fundamentales de un modelo de red: • Los registros contienen campos que necesitan una organización jerárquica. • Los conjuntos se utilizan para definir relaciones de uno a varios entre registros que contienen un propietario, muchos miembros. • Un registro puede actuar como propietario en cualquier número de conjuntos y como miembro en cualquier número de conjuntos. Un conjunto es definido como dos tipos de registro, los cuáles están ligados con una relación muchos a muchos (M:N). • Un registro en el nodo miembro no puede existir sin estar relacionado con un registro existente en el nodo propietario. Por ejemplo, un cliente debe asignarse a un agente, pero un agente sin clientes aún puede aparecer en la base de datos. Un conjunto se diseña con la ayuda de listas circulares enlazadas donde un tipo de registro, el propietario del conjunto también llamado padre, aparece una vez en cada círculo, y un segundo tipo de registro, también conocido como subordinado o hijo, puede aparecer múltiples veces en cada círculo. Se establece una jerarquía entre dos tipos de registros en los que un tipo (A) es propietario de otro tipo (B). Al mismo tiempo, se puede desarrollar otro conjunto donde el último conjunto (B) es el propietario del primer conjunto (A). En este modelo, la propiedad se define por la dirección, por lo que todos los conjuntos comprenden un gráfico dirigido general. El acceso a los registros se desarrolla mediante la estructura de indexación de listas enlazadas circulares. 14 Ejemplo2: Los vendedores de leche pueden distribuir determinados productos en algunas ciudades de la costa. Cada producto puede ser distribuido por más de un vendedor, así mismo cada vendedor puede distribuir en diferentes ciudades. Figura 4. Representación de un modelo de datos de red. Características El modelo de red tiene las siguientes características principales: • Puede representar la redundancia en los datos de manera más eficiente que en el modelo jerárquico. • Puede haber más de una ruta desde un nodo anterior a los nodos sucesores. • Las operaciones del modelo de red se mantienen mediante la estructura de indexación de la lista enlazada (circular) donde un programa mantiene una posición actual y navega de un registro a otro siguiendo las relaciones en las que participa el registro. • Los registros también se pueden localizar proporcionando valores clave. Ventajas El modelo de red conserva casi todas las ventajas del modelo jerárquico al tiempo que elimina algunas de sus deficiencias. Las principales ventajas del modelo de red son: • Simplicidad conceptual: Al igual que el modelo jerárquico, el modelo de red es también conceptualmente simple y fácil de diseñar. • Capacidad para manejar más tipos de relaciones: El modelo de red puede manejar las relaciones de uno a muchos (1: M) y de muchos a muchos (M:N), lo que es una ayuda real para modelar las situaciones de la vida real. 2 https://www.dataprix.com/es/mineria-datos-aplicada-encuesta-permanente-hogares/262-bases-datos-red 15 • Facilidad de acceso a los datos: El acceso a los datos es más fácil y flexible que el modelo jerárquico. • Integridad de los datos: El modelo de red no permite que un miembro exista sin un propietario. Por lo tanto, un usuario debe definir primero el registro de propietario y luego el registro de miembro. Esto asegura la integridad de los datos. • Independencia de los datos: El modelo de red es mejor que el modelo jerárquico para aislar los programas de los complejos detalles de almacenamiento físico. • Estándares de bases de datos: Uno de los principales inconvenientes del modelo jerárquico fue la no disponibilidad de estándares universales para el diseño y modelado de bases de datos. El modelo de red se basa en los estándares formulados por DBTG y aumentados por ANSI / SPARC (Instituto Nacional Estadounidense de Estándares / Comité de Requisitos y Planificación de Estándares) en la década de 1970. Todos los sistemas de gestión de bases de datos de la red se ajustaban a estos estándares. Estos estándares incluyen un lenguaje de definición de datos (DDL) y el lenguaje de manipulación de datos (DML), lo que mejora enormemente la administración y portabilidad de la base de datos. Desventajas Entre sus desventajas encontramos: • Complejidad del sistema: Todos y cada uno de los registros deben mantenerse con la ayuda de punteros, lo que hace que la estructura de la base de datos sea más compleja. • Defectos funcionales: Debido a que una gran cantidad de punteros es esencial, la inserción, las actualizaciones y la eliminación se vuelven más complejas. • Falta de independencia estructural: Un cambio en la estructura también exige un cambio en la aplicación, lo que conduce a una falta de independencia estructural. • Flexibilidad incompleta: Aunque más flexible que el modelo jerárquico, el modelo de red aún no puede satisfacer todas las relaciones asignando otro propietario. 2.3 Modelo de datos relacional: Características básicas El modelo relacional representa la base de datos como una colección de relaciones (Beynon-Davies, 2018), la que expresa la base de datos como un conjunto de relaciones (tabla de valores). Cada relación tiene columnas y filas que se denominan formalmente atributos y tuplas, respectivamente. Cada tupla en relación es una entidad o relación del mundo real. El 16 nombre de la relación y el nombre de los atributos contribuyen a interpretar el sentido de cada tupla. Su idea fundamental es el uso de relaciones. Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados tuplas. 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 estos se almacenen no tiene relevancia. El modelo de datos relacional proporciona herramientas conceptuales para diseñar el esquema de base de datos de la base de datos relacional. Es decir, describe los datos, la relación entre esos datos, la semántica de los datos y las restricciones sobre los datos en la base de datos relacional. Ejemplo3: La Figura 5 muestra las relaciones entre Clientes que hacen Compras. Las compras tienen uno o más Productos, y estos productos son distribuidos por proveedores. Figura 5. Representación de un modelo de datos relacional. Características El modelo de datos relacional presenta las siguientes características: • La base de datos es un conjunto de relaciones relacionadas (tabla de valores). • Cada relación tiene un nombre que indica qué tipo de tuplas tiene la relación. Por ejemplo, una relación denominada "Estudiante" indica que tiene entidades de estudiante. 3 https://sites.google.com/site/michellesyllabus/unidad-2-implementacion-de-base-de-datos-relacionales/2-2modelos-relacionales 17 • Cada relación tiene un conjunto de atributos (nombres de columna) que representa qué tipo de información tienen las entidades o tuplas. • Una tupla (fila) en una relación, es una entidad del mundo real, tiene un conjunto de valores para los atributos correspondientes. • Cada valor de datos en una fila o tupla se llama campo. Ventajas El modelo relacional es uno de los modelos de base de datos más utilizados. Algunas de las ventajas clave de un modelo de datos relacional son: • El acceso a los datos no se ve afectado por los cambios en la estructura de la base de datos. • Es más fácil mantener la seguridad en comparación con otros modelos. • Puede utilizar bases de datos relacionales con poca o ninguna formación. • Las entradas de la base de datos se pueden modificar sin especificar todo el cuerpo. • Evitan errores al permitir que un registro se aplique a cualquier número de otras tablas. Por ejemplo, puede hacer referencia a un registro secundario en una relación 'es el hijo de' y puede usar el mismo registro en una tabla de 'niños que asisten a un evento de la empresa'. Esto ayuda a evitar la replicación y puede usar la misma información de varias formas, sin cambiar involuntariamente ningún registro. • Son eficientes para proporcionar otros tipos de datos ocultos en los registros, utilizando consultas escritas en SQL. Esto le permite explorar la base de datos de formas que no son evidentes de inmediato, como encontrar a todos los niños mayores de cierta edad o a todos los padres con tres o más niños. Desventajas En el caso de una base de datos relacional, los datos están normalizados, lo que significa muchas uniones. Esto puede afectar el rendimiento. Además, tiene problemas para trabajar con datos semiestructurados porque no obedecen a la estructura tabular de los modelos de datos asociados. En general, una base de datos relacional tiene los siguientes inconvenientes: • El mapeo de objetos en una base de datos relacional puede tornarse complejo. • Se incurre en gastos generales de hardware que lo hacen costoso. • La base de datos relacional oculta las complejidades de la implementación y los detalles de almacenamiento de datos físicos de los usuarios. 18 Sabías que: El Registro de Windows usan modelo de datos jerárquico. Tema 3: Fases de diseño El diseño de bases de datos es una colección de procesos que facilitan el diseño, desarrollo, implementación y mantenimiento de sistemas de gestión de datos empresariales. Las bases de datos correctamente diseñadas son fáciles de mantener, mejoran la coherencia de los datos y son rentables en términos de espacio de almacenamiento en disco (Cobo, 2007). El diseñador de la base de datos decide cómo se correlacionan los elementos de datos y qué datos deben almacenarse. En esta sección veremos el proceso de diseño de la base de datos en términos de especificidad. Así como cualquier diseño comienza en un nivel alto y avanza hacia un nivel de detalle cada vez mayor, también lo hace el diseño de bases de datos. Por ejemplo, al construir una casa, comienza con cuántos dormitorios y baños tendrá la casa, si será de una o varias plantas, etc. El siguiente paso es conseguir que un arquitecto diseñe la casa desde una perspectiva más estructurada. perspectiva. Este nivel se vuelve más detallado con respecto al tamaño real de las habitaciones, cómo se conectará la casa, dónde se colocarán los accesorios de plomería, etc. El último paso es contratar a un contratista para construir la casa. Eso es mirar el diseño desde un alto nivel de abstracción hasta un nivel de detalle cada vez mayor. El diseño de la base de datos se parece mucho a eso. Comienza con la identificación de los usuarios de las reglas comerciales. Luego, los diseñadores y analistas de la base de datos crean el diseño de la base de datos. Finalmente, el administrador de la base de datos implementa el diseño usando un SGBD. Las siguientes subsecciones resumen los modelos en orden decreciente de nivel de abstracción. 3.1 Niveles de abstracción: conceptual, lógico y físico Existen tres tipos diferentes de arquitectura de modelos de datos: modelos de datos conceptuales, modelos de datos lógicos y modelos de datos físicos, y cada uno tiene un propósito específico. Los modelos de datos se utilizan para representar los datos y cómo se almacenan en la base de datos y para establecer la relación entre los elementos de datos. • Modelo de datos conceptual: este modelo de datos define QUÉ contiene el sistema. Este modelo lo suelen crear las partes interesadas de la empresa y los arquitectos de datos. El propósito es organizar, ampliar y definir conceptos y reglas comerciales. 19 • Modelo de datos lógicos: define CÓMO se debe implementar el sistema independientemente del SGBD. Este modelo lo suelen crear arquitectos de datos y analistas de negocios. El propósito es desarrollar un mapa técnico de reglas y estructuras de datos. • Modelo de datos físicos: este modelo de datos describe CÓMO se implementará el sistema utilizando un sistema SGBD específico. Este modelo lo suelen crear DBA y desarrolladores. El propósito es la implementación real de la base de datos. Figura 6. Tipo de modelos de datos. Modelo de datos conceptual Un modelo de datos conceptual es una vista organizada de los conceptos de la base de datos y sus relaciones. El propósito de crear un modelo de datos conceptual es establecer entidades, sus atributos y relaciones. En este nivel de modelado de datos, apenas hay detalles disponibles sobre la estructura real de la base de datos. Las partes interesadas comerciales y los arquitectos de datos suelen crear un modelo de datos conceptual. Los 3 conceptos básicos de un modelo de datos conceptual son • Entidad: Algo del mundo real • Atributo: Características o propiedades de una entidad. • Relación: dependencia o asociación entre dos entidades 20 Como ejemplos de modelo de datos conceptual encontramos: • Cliente y Producto son dos entidades. • El número y el nombre del cliente son atributos de la entidad Cliente. • El nombre y el precio del producto son atributos de la entidad Producto • La venta es la relación entre el cliente y el producto. Un modelo de datos conceptual posee las siguientes características: • Ofrece una cobertura de toda la organización de los conceptos comerciales. • Este tipo de modelos de datos están diseñados y desarrollados para una audiencia empresarial. • El modelo conceptual se desarrolla independientemente de las especificaciones de hardware, como la capacidad de almacenamiento de datos, la ubicación o las especificaciones de software, como el proveedor y la tecnología de SGBD. El objetivo es representar los datos como los verá un usuario en el "mundo real". Los modelos de datos conceptuales son conocidos como modelos de dominio y crean un vocabulario común para todas las partes interesadas al establecer conceptos básicos y alcance. Figura 7. Modelo de datos conceptual. Modelo de datos lógico El modelo lógico de datos se utiliza para definir la estructura de los elementos de datos y establecer relaciones entre ellos. El modelo de datos lógicos agrega más información a los elementos del modelo de datos conceptual. La ventaja de utilizar un modelo de datos lógicos es proporcionar una base para formar la base del modelo físico. Sin embargo, la estructura de modelado sigue siendo genérica. 21 En este nivel de modelo de datos, no se define ninguna clave primaria o secundaria. Más bien se debe verificar y ajustar los detalles del conector que se establecieron anteriormente para las relaciones. Un modelo de datos lógico posee las siguientes características: • Describe las necesidades de datos para un solo proyecto, pero podría integrarse con otros modelos de datos lógicos según el alcance del proyecto. • Diseñado y desarrollado independientemente del SGBD. • Los atributos de datos tendrán tipos de datos con precisión y longitud exactas. • Los procesos de normalización al modelo se aplican típicamente hasta 3NF. Figura 8. Modelo de datos lógico. Modelo de datos físico Un modelo de datos físico describe una implementación específica de la base de datos del modelo de datos. Ofrece una abstracción de la base de datos y ayuda a generar el esquema. Esto se debe a la riqueza de metadatos que ofrece un modelo de datos físicos. El modelo de datos físicos también ayuda a visualizar la estructura de la base de datos al replicar claves de columna de la base de datos, restricciones, índices, disparadores y otras características de SGBDR. Figura 9. Modelo de datos físico. 22 Las características de un modelo de datos físicos son: • El modelo de datos físicos describe la necesidad de datos para un solo proyecto o aplicación, aunque puede integrarse con otros modelos de datos físicos según el alcance del proyecto. • El modelo de datos contiene relaciones entre tablas que tratan la cardinalidad y la nulabilidad de las relaciones. • Desarrollado para una versión específica de un SGBD, ubicación, almacenamiento de datos o tecnología que se utilizará en el proyecto. • Las columnas deben tener tipos de datos exactos, longitudes asignadas y valores predeterminados. • Se definen claves primarias y externas, vistas, índices, perfiles de acceso y autorizaciones, etc. 3.2 Modelo entidad-relación Antes de hablar sobre el modelo entidad-relación (ER) es necesario introducir el concepto de diagrama ER que muestra la relación de los conjuntos de entidades almacenados en una base de datos. En otras palabras, los diagramas ER ayudan a explicar la estructura lógica de las bases de datos. Los diagramas ER se crean en base a tres conceptos básicos: entidades representadas mediante rectángulos, atributos representados mediante óvalos y relaciones representados mediante rombos. El propósito del diagrama ER es representar la infraestructura del marco de la entidad. El modelo ER es un diagrama de modelo de datos conceptual de alto nivel y ayuda a analizar sistemáticamente los requisitos de datos para producir una base de datos bien diseñada. El modelo ER representa entidades del mundo real y las relaciones entre ellas. Los diagramas ER son una herramienta visual que es útil para representar el modelo ER. ¿Por qué utilizar diagramas ER? Las principales razones para utilizar el diagrama ER son: • Ayuda a definir términos relacionados con el modelado de relaciones entre entidades • Proporciona una vista previa de cómo deben conectarse todas sus tablas y qué campos estarán en cada tabla • Ayuda a describir entidades, atributos, relaciones. 23 • Se pueden traducir a tablas relacionales, lo que le permite crear bases de datos rápidamente • Las personas encargadas de diseñar bases de datos pueden utilizar los diagramas ER como un modelo para implementar datos en aplicaciones de software específicas. • Permite comunicarse con la estructura lógica de la base de datos a los usuarios. Símbolos y notaciones de diagramas ER Como se mencionó anteriormente, para diagramar ER se usan tres símbolos básicos que son el rectángulo, óvalo y rombo para representar relaciones entre elementos, entidades y atributos. Hay algunos sub-elementos que se basan en los elementos principales del diagrama ER. A continuación, se muestran los componentes principales y sus símbolos en los diagramas ER: • Rectángulo: Representa tipos de entidades como cosas, objetos, conceptos del mundo real que pueden ser concretos o abstractos. Se puede asociar a las entidades con sustantivos, Por ejemplo, una persona, casa o un carro son entidades concretas, mientras que una asignatura o un trabajo son entidades abstractas. Una relación también se conoce como tabla. Dentro de una tabla, cada fila representa un grupo de valores de datos relacionados. Una fila o registro también se conoce como tupla. Las columnas de una tabla son un campo y también se las denomina atributo. Los nombres de las tablas deben ser únicos en la base de datos. • Elipse: Representa los atributos de una entidad. Es decir, son las características que identifican o definen una entidad. Por ejemplo, la entidad persona tiene atributos como cédula, nombres, apellidos, sexo, edad. Los nombres de los atributos tienen que ser únicos dentro de cada entidad. • Rombo: Representa tipos de relaciones entre las entidades. Es decir, cómo las entidades interactúan o se asocian entre sí. Piensen en las relaciones como si fueran verbos. Por ejemplo, el estudiante mencionado podría inscribirse en un curso. Las dos entidades serían el estudiante y el curso, y la relación representada es el acto de inscribirse, que conecta ambas entidades de ese modo. • Líneas: Vincula atributos a tipos de entidad y tipos de entidad con otros tipos de relación. 24 Figura 10. Ejemplo de un diagrama ER. En la Figura 10 existen dos entidades: ALUMNO y CURSO. La relación es INSCRIBE y los atributos de la entidad ALUMNO son Matrícula y Nombre por dar un ejemplo. Recuerde que: Una base de datos se compone de varias tablas y cada tabla contiene los datos. En cada tabla, el orden o la secuencia de columnas o filas es insignificante. 3.3 Entidad: fuerte, débil; supertipo, subtipo Como se abordó en la subsección anterior, una entidad puede ser un lugar, una persona, un objeto, un evento o un concepto, que almacena datos en la base de datos. Las características de las entidades es que deben tener un atributo y una clave única. Cada entidad está formada por algunos atributos que representan esa entidad. Como ejemplos de entidades encontramos: • Persona: Empleado, estudiante, paciente • Lugar: Tienda, edificio • Objeto: Máquina, producto y automóvil • Evento: Venta, registro, renovación • Concepto: Cuenta, curso Tipos de entidades Las entidades pueden existir por sí mismas o solo pueden existir cuando están asociadas con algún otro tipo de entidad. Podemos diferenciar dos tipos de entidades en base a su asociación: • Entidad fuerte: Es un tipo de entidad que si tiene un atributo considerado como clave primaria. • Entidad débil: Es un tipo de entidad que no tiene un atributo como clave primaria, es decir, necesita de una entidad fuerte para existir. Por este motivo Puede identificarse de forma 25 única considerando la clave principal de otra entidad. Para eso, los conjuntos de entidades débiles deben tener participación. Los registros que pertenecen a una entidad débil son identificados por estar relacionados con registros específicos de una entidad fuerte. Figura 11. Símbolos y significados de entidades y relaciones. Por ejemplo, en un video-club que renta videos, las copias tienen que estar asociadas a una película. Por lo tanto, la entidad COPIA es débil y depende de la entidad PELÍCULA. El diagrama ER quedaría así: Figura 12. Diagrama ER de un video-club4 De igual forma, si queremos diagramar el modelo ER de los movimientos bancarios de los movimientos de una cuenta bancaria y las transacciones realizadas, quedaría de la siguiente forma: 4 http://dryvalleycomputer.com/index.php/bases-de-datos/el-modelo-entidadrelacion/56-entidades-fuertes-ydebiles 26 Figura 13. Diagrama ER de movimientos bancarios5 Nótese que la clave primaria de la Figura 13 está asociada con la entidad fuerte que es CUENTA. Recordar que la entidad TRANSACCIÓN puede identificarse con un número de transacción, pero no tiene sentido sin estar asociada con una cuenta bancaria. Tabla 1 Diferencias entre entidades fuertes y débiles Entidad fuerte Siempre tiene una clave primaria. Está representado por un símbolo de rectángulo. Contiene una clave principal representada por el símbolo de subrayado. La relación entre dos conjuntos de entidades fuertes se muestra mediante el uso de un símbolo de rombo. Entidad débil No tiene suficientes atributos para construir una clave primaria. Está representado por un símbolo de doble rectángulo. Contiene una clave parcial que puede representarse por un símbolo de subrayado discontinuo. La relación entre un conjunto de entidades fuerte y débil se muestra mediante el símbolo de doble rombo. A menudo, algunas instancias de una entidad tienen atributos y / o relaciones que otras instancias no tienen. Imaginen una empresa que necesita realizar un seguimiento de los pagos de los clientes. Los clientes pueden pagar en efectivo, con cheque o con tarjeta de crédito. Todos los pagos tienen algunos atributos comunes: fecha de pago, monto del pago, etc. Pero solo las tarjetas de crédito tendrían un atributo de "número de tarjeta". Y para pagos con tarjeta de crédito y cheques, es posible que necesitemos saber qué CLIENTE realizó el pago, aunque esto no es necesario para pagos en efectivo. ¿Deberíamos crear una sola entidad de 5 https://virtual.itca.edu.sv/Mediadores/dbd/u1/entidades_dbiles.html 27 PAGO o tres entidades separadas EFECTIVO, CHEQUE y TARJETA DE CRÉDITO? ¿Y qué pasa si en el futuro introducimos un cuarto método de pago? A veces, tiene sentido subdividir una entidad en diferentes tipos. Este puede ser el caso cuando un grupo de instancias tiene propiedades especiales, como atributos o relaciones que existen solo para ese grupo o, por otro lado, atributos que pueden ser compartidos entre entidades. Dependiendo de si comparte o no atributos, las entidades pueden estar clasificadas en supertipo y subtipo, donde la entidad supertipo puede ser considerada la entidad padre y la entidad subtipo como entidad hijo: • Supertipo: Es un tipo de entidad que tiene relación con uno o más subtipos y contiene atributos que son comunes a los subtipos. • Subtipo: Son subgrupos dentro de las entidades supertipo que tienen atributos únicos, pero que serán distintos para cada subtipo. Posee las siguientes características o Hereda todos los atributos del supertipo o Hereda todas las relaciones del supertipo o Por lo general, tiene sus propios atributos o relaciones. o Se dibuja dentro del supertipo o Nunca existe solo o Puede tener subtipos propios Las claves primarias de las entidades supertipo y subtipo son siempre idénticas. Por ejemplo, al diseñar la base de datos para personas, se puede definir a una entidad supertipo llamada PERSONA y sus entidades subtipo pueden ser VENDEDOR, CLIENTE Y EMPLEADO. La entidad PERSONA puede tener atributos como cédula, nombres, dirección, teléfono que son comunes a las entidades subtipo descritas anteriormente. Y a las tres entidades subtipo, se pueden agregar atributos específicos a cada una de ellas. La entidad SEGURO es supertipo y entidades como SEGURO DE SALUD, SEGURO CONTRA ACCIDENTES o SEGURO DE MUERTE se consideran subtipo. La entidad TARJETA DE CRÉDITO es supertipo, mientras que TARJETA DE TRANSFERENCIA, CRÉDITO DE REEMBOLSO EN EFECTIVO o TARJETA DE CREDITO ESTUDIANTIL son consideradas entidades subtipo. 28 Figura 14. Visualización de entidades supertipo y subtipo. 3.4 Atributos: simples, compuestos; monovalentes, multivalentes; derivados Es una propiedad de valor único de un tipo de entidad o de un tipo de relación. Por ejemplo, una conferencia puede tener atributos: hora, fecha, duración, lugar, etc. Un atributo en el diagrama ER está representado por un óvalo. Tabla 2. Tipos de atributos existentes en un diagrama ER Tipo Simple Compuesto Monovalente Multivalente Derivado Descripción Los atributos simples no se pueden dividir más. Por ejemplo, el número de teléfono de un estudiante. También se le llama valor atómico. Es posible descomponer el atributo compuesto. Por ejemplo, el nombre completo de un estudiante se puede dividir en nombre, segundo nombre y apellido. Una instancia de un atributo monovalente puede contener un solo valor. Por ejemplo, la cédula de un estudiante. Pueden tener más de un valor. Por ejemplo, un estudiante puede tener más de un número de teléfono o dirección de correo electrónico. Este tipo de atributo no se incluye en la base de datos física. Sin embargo, sus valores se derivan de otros atributos presentes en la base de datos. Por ejemplo, la edad no debe almacenarse directamente, sino que se deriva de la fecha de nacimiento. Igual con el salario promedio que se deduce del promedio de todos los salarios. 3.5 Identificadores: internos, externos, mixtos; simples y compuestos La razón para tener una base de datos es almacenar valores de datos sobre entidades y luego recuperar los valores de datos sobre esas entidades según sea necesario. Para lograr esto, debe haber alguna forma de distinguir una entidad de otra. Los identificadores de entidad 29 realizan esta función. Los identificadores de entidad son atributos, específicamente, atributos clave que identifican de forma única a cada entidad. El nombre de un objeto de base de datos se conoce como su identificador. Cualquier elemento de dentro de una base de datos puede tener un identificador. Servidores, bases de datos y objetos de bases de datos, como tablas, vistas, columnas, índices, desencadenadores, procedimientos, restricciones, reglas, etc. pueden tener identificadores. Se requiere que la mayor parte de los objetos tengan identificadores. Pero para ciertos objetos, como las restricciones, son opcionales. El identificador de un objeto se crea cuando se define el objeto. A continuación, el identificador se utiliza para hacer referencia al objeto. Por ejemplo, en la Figura 15 se observa que la sentencia SQL crea una tabla con el identificador TableX y dos columnas con los identificadores KeyCol y Description: Figura 15. Identificadores dentro de una sentencia SQL6. Un identificador de entidad no es un atributo opcional; cada entidad debe tener un atributo clave para identificarla de forma única. Los identificadores de entidad (atributos clave) se convierten en claves primarias en una tabla. Existen diversos tipos de identificadores: • Identificador interno: Si el identificador está formado por uno o más atributos de la propia entidad. En este caso hablamos de un identificador interno que se transforma en clave primaria de una tabla. Por ejemplo, un identificador interno para la entidad AUTOMÓVIL con atributos Matrícula, Modelo, y Color, será el atributo Matrícula, asumiendo que no pueden existir dos vehículos con la misma matrícula. De la misma forma, un identificador interno para la entidad PERSONA con atributos Cédula, Nombres y Fecha de nacimiento, será Cédula el identificador interno asumiendo nuevamente que no pueden existir personas con el mismo número de cédula. 6 https://docs.microsoft.com/es-es/sql/relational-databases/databases/database-identifiers?view=sql-server-ver15 30 Figura 16. Identificadores internos dentro de entidades. • Identificador externo: A veces, sin embargo, los atributos de una entidad no son suficientes para identificar sus ocurrencias sin ambigüedades. Considere, por ejemplo, la entidad ESTUDIANTE en la Figura 17. A primera vista, puede parecer que el atributo Registro puede ser un identificador de dicha entidad, pero no es así. El esquema, de hecho, describe a los estudiantes matriculados en varias universidades, y dos estudiantes matriculados en diferentes universidades podrían tener el mismo número de registro. En este caso, para identificar a un estudiante de forma inequívoca, necesitamos la universidad correspondiente, así como el número de matrícula. Así, un identificador correcto para la entidad ESTUDIANTE en este esquema se compone del atributo Registro y de la entidad UNIVERSIDAD. A esto se le llama un identificador externo. Cabe señalar que esta identificación es posible gracias a la relación obligatoria uno a muchos (1:M) entre las entidades UNIVERSIDAD y ESTUDIANTE, que asocia a cada estudiante con una sola universidad. Así, una entidad E puede ser identificada por otras entidades solo si cada una de estas entidades está involucrada en una relación en la que E participa con cardinalidad (1,1). 31 Figura 17. Identificadores externos dentro de entidades. En base a lo que hemos dicho sobre el tema de los identificadores, podemos hacer algunas observaciones generales: • Un identificador puede involucrar uno o más atributos, siempre que cada uno de ellos tiene una cardinalidad (1:1). • Un identificador externo puede involucrar a una o más entidades, siempre que cada una de ellas sea miembro de una relación en la que participa la entidad a identificar con cardinalidad igual (1:1). • Un identificador externo puede involucrar a una entidad que a su vez está identificada externamente, siempre que no se generen ciclos. • Cada entidad debe tener un identificador (interno o externo), pero puede tener más de uno. En realidad, si hay más de un identificador, el indicador se denomina mixto. Cada entidad tiene al menos un identificador. En este paso, se trata de encontrar todos los identificadores de cada una de las entidades. Los identificadores pueden ser simples o compuestos. De cada entidad se escoger uno de los identificadores como clave primaria en la fase del diseño lógico. • Identificador simple: Cuando una clave principal está relacionada con una sola columna, solo se puede asignar un atributo en el identificador principal. • Identificador compuesto: Cuando la clave primaria está relacionada con más de una columna Cada entidad puede tener múltiples identificadores alternativos como se muestra en la Figura 18. Todos los identificadores de las entidades se deben anotar en el diccionario de datos. 32 Figura 18. Tipos de identificadores dentro de una base de datos. 3.6 Grado de una relación: unaria, binaria, ternaria, n-aria El grado de una relación es el número de tipos de entidades que participan o se asocian en una relación. Al ver un diagrama ER, simplemente podemos decir el grado de una relación, es decir, el número de un tipo de entidad que está conectado a una relación es el grado de esa relación. Según el número de tipos de entidad que están conectados, tenemos el siguiente grado de relaciones: unaria, binaria, ternaria y n-aria • Unaria: Existe una relación unaria cuando ambos tipos de entidad participante son iguales. Cuando existe tal relación, decimos que el grado de relación es 1. Por ejemplo, supongamos que en un aula tenemos muchos estudiantes que pertenecen a un club de baile y de baloncesto y algunos de ellos son líderes de club. Entonces, un grupo particular de estudiantes es administrado por su respectivo líder de club. Aquí, el grupo está formado por estudiantes y también, los líderes del club se eligen entre los estudiantes. Entonces, la entidad ESTUDIANTE es la única entidad que participa aquí. Podemos representar esta relación usando el diagrama ER de la siguiente manera: 33 Figura 19. Relación unaria. • Binaria: Existe una relación binaria cuando participan exactamente dos tipos de entidad. Cuando existe tal relación, decimos que el grado es 2. Este es el grado de relación más común. Es fácil lidiar con esta relación, ya que se pueden convertir fácilmente en tablas relacionales. Por ejemplo, tenemos dos tipos de entidad, CLIENTE y CUENTA, donde cada cliente tiene una cuenta que almacena los detalles de la cuenta del cliente. Dado que tenemos dos tipos de entidades que participan, lo llamamos una relación binaria. Además, un CLIENTE puede tener muchas CUENTAS, pero cada CUENTA debe pertenecer a un solo CLIENTE. Podemos decir que es una relación binaria de uno a muchos. Figura 20. Relación binaria. • Ternaria: Existe una relación ternaria cuando participan exactamente tres tipos de entidad. Cuando existe tal relación, decimos que el grado es 3. A medida que aumenta el número de entidades en la relación, se vuelve complejo convertirlas en tablas relacionales. Por ejemplo, tenemos tres tipos de entidad EMPLEADO, DEPARTAMENTO y UBICACIÓN. La relación entre estas entidades se define como un empleado trabaja en un departamento, un empleado trabaja en una ubicación 34 particular. Entonces, podemos ver que tenemos tres entidades participando en una relación, por lo que es una relación ternaria. Figura 21. Relación ternaria. • N-aria: Existe una relación N-aria cuando participan "n" entidades. Entonces, cualquier número de entidades puede participar en una relación. No hay limitación al número máximo de entidades que pueden participar. Pero las relaciones con un grado superior no son comunes. Esto se debe a que la conversión de relaciones de grado superior en tablas relacionales se vuelve compleja. Estamos haciendo un modelo ER porque se puede convertir fácilmente en cualquier otro modelo para implementar la base de datos. Pero este beneficio no está disponible si usamos relaciones de mayor grado. Por tanto, las relaciones binarias son más populares y utilizadas. Representamos una relación N-aria de la siguiente manera: Figura 22. Relación ternaria. En el ejemplo anterior, E1 denota el primer tipo de entidad, E2 denota el segundo tipo de entidad y así sucesivamente. R representa la relación. Entonces, aquí tenemos un 35 total de 5 tipos de entidades que participan en la relación. Por lo tanto, el grado de la relación n-aria anterior es 5. 3.7 Cardinalidad de correspondencia de clases La cardinalidad se especifica para cada entidad que participa en una relación y describe el número máximo y mínimo de ocurrencias de relación en las que una ocurrencia de entidad puede participar. Por lo tanto, establece cuántas veces en una relación entre entidades una ocurrencia de una de estas entidades puede estar vinculada a ocurrencias de las otras entidades involucradas. Por ejemplo, supongamos que en una relación ASIGNAR entre las entidades EMPLEADO y TAREA especificamos para la primera entidad una cardinalidad mínima igual a uno y una cardinalidad máxima igual a cinco. Esto significa que deseamos indicar que un empleado puede participar en un mínimo de una y un máximo de cinco ocurrencias de la relación de ASIGNAR. En otras palabras, deseamos decir que, en nuestra aplicación, se debe asignar al menos una tarea a un empleado, pero no más de cinco. Nuevamente, suponga que para la entidad TAREA especificamos una cardinalidad mínima igual a cero y una cardinalidad máxima igual a 50. En este caso, solo imponemos la restricción de que una tarea puede aparecer en un máximo de 50 ocurrencias de la relación ASIGNAR. Así, una determinada tarea podría no ser asignada a ningún empleado o podría asignarse a 50 o menos empleados. En un esquema ER, las cardinalidades mínima y máxima de la participación de las entidades en las relaciones se especifican entre paréntesis. Figura 23. Cardinalidad de una relación. En principio, es posible asignar cualquier entero no negativo a la cardinalidad de una relación con la única restricción de que el mínimo la cardinalidad debe ser menor o igual que la cardinalidad máxima. En la mayoría de los casos, sin embargo, es suficiente usar solo tres valores: cero, uno y el símbolo "M" (que se llama "muchos" e indica genéricamente un número entero mayor que uno): 36 • Asociación de (1:1): Cuando decimos que hay una relación 1:1 entre dos entidades, significa que por cada ocurrencia de una entidad hay exactamente una ocurrencia de una entidad relacionada. Las relaciones (1:1) no son muy frecuentes en los modelos de datos. A menudo, este tipo de relación se puede capturar suficientemente dentro de una sola entidad. Dividimos estos valores en tablas separadas con una relación de (1:1) cuando se obtiene una ventaja de rendimiento utilizando la tabla separada. Por ejemplo, la entidad PAÍS con la entidad CAPITAL maneja una relación (1:1) ya que cada país tiene exactamente una capital y viceversa. La cardinalidad “uno” puede ser representada visualmente con una raya vertical. Figura 24. Relación (1:1). • Asociación de (1:M): Cuando decimos que hay una relación 1:M entre dos entidades, significa que por cada ocurrencia de una entidad hay dos o muchas ocurrencias de una entidad relacionada. Es una de las relaciones más comunes en las bases de datos. Por ejemplo, cada ciudad está en exactamente un país, pero la mayoría de los países tienen muchas ciudades. La cardinalidad “muchos” se lo representa visualmente con el siguiente símbolo 37 Figura 25. Relación (1:M). • Asociación (M:N): Cuando decimos que hay una relación M:N entre dos entidades relacionadas, significa que para cada ocurrencia de cualquiera de las entidades, hay dos o muchas ocurrencias de la otra entidad. Por ejemplo, un estudiante puede inscribirse en muchas clases y una clase puede tener muchos estudiantes matriculados. Figura 26. Relación (M:N). Para fortalecer las bases de datos, es necesario establecer la clase de membresía que se refiere a la condición de participación, la cual puede ser de tipo obligatoria u opcional: • Participación obligatoria: En la participación obligatoria, para cada instancia de la entidad A, debe existir una instancia de la entidad B y viceversa. Un ejemplo de participación obligatoria sería la relación entre madre e hijo. La entidad del HIJO existiría sólo si hubiera una MADRE y, de manera similar, una MADRE existiría solo si hubiera un HIJO. Se lo puede representar visualmente con un círculo relleno. 38 Figura 27. Participación obligatoria. • Participación opcional: En participación opcional, no es necesario que todas las instancias de la entidad participen en una relación. Puede ser que el número de instancias que participan para una entidad en particular sea incluso cero. La participación opcional es buena para representar relaciones que no son obligatorias o pueden ser temporales, es decir, relaciones que pueden cambiar durante un período de tiempo. La relación podría ser obligatoria para la primera entidad y opcional para la segunda, o al revés. O puede ser opcional para ambas. Por ejemplo, un ARTISTA debe estar representado por un AGENTE, pero un agente no tiene que representar a un artista. Por lo tanto, la relación es obligatoria para un artista intérprete o ejecutante, pero opcional para un agente. Figura 28. Participación opcional en la entidad AGENTE. 39 3.8 Cardinalidad de cobertura de clases Las jerarquías de generalización presentan la propiedad de cobertura. La cobertura puede ser parcial o total y exclusiva o superpuesta. De forma general, podemos decir que la cobertura parcial o total permite especificar una restricción entre el tipo de entidad genérica y sus tipos de entidad subconjunto, donde todos los elementos del tipo de entidad genérica deben pertenecer a alguno de sus tipos de entidad subconjunto (si es total), o no (si es parcial). La cobertura exclusiva o superpuesta permite especificar una restricción entre los tipos de entidad subconjunto, donde los elementos que pertenecen a un tipo de entidad subconjunto pueden pertenecer también a otro tipo de entidad subconjunto (si es superpuesto) o no (si es exclusiva). • Parcial: Especifica que cada entidad del conjunto de entidades puede participar o no en la instancia de relación de ese conjunto de relaciones. Por eso, también se denomina participación opcional. La participación parcial se representa mediante una única línea entre el conjunto de entidades y el conjunto de relaciones. Por ejemplo, una línea entre la entidad CURSO y la relación "enrolar" significa participación parcial. Especifica que pueden existir algunos cursos para los que no se realizan enrolamientos o matriculaciones. Figura 29. Participación parcial en la entidad CURSO. • Total: Especifica que cada entidad en el conjunto de entidades debe participar obligatoriamente en al menos una instancia de relación en ese conjunto de relaciones. Por eso, también se denomina participación obligatoria. La participación total se representa mediante una línea doble entre el conjunto de entidades y el conjunto de relaciones. Por ejemplo, la línea doble entre la entidad ESTUDIANTE y la relación "enrolar" significa participación total. Especifica que cada alumno debe estar enrolado o matriculado en al menos un curso. 40 Figura 30. Participación total en la entidad ESTUDIANTE. • Exclusiva: Los elementos que pertenecen a una entidad no pueden pertenecer a otra entidad. Por ejemplo, el sexo de una persona es mujer u hombre. • Superpuesta: Los elementos que pertenecen a una entidad pueden pertenecer también a otra entidad. Por ejemplo, un empleado de una universidad puede ser al mismo tiempo administrativo y dar clases. En la Figura 31 se evidencian algunos ejemplos prácticos de como se pueden combinar la cobertura de clases, donde t significa total, p parcial, e exclusiva y s superpuesta. Figura 31. Combinación de la cobertura de clases. 41 Tema 4: Esquema conceptual y lógico El diseño de la base de datos se llama esquema. Esto nos habla de la vista estructural de la base de datos y da una descripción general de la base de datos. Un esquema de base de datos define cómo se organizan los datos utilizando el diagrama de esquema. Un diagrama de esquema es un diagrama que contiene entidades y los atributos que definirán ese esquema. Un diagrama de esquema solo nos muestra el diseño de la base de datos. No muestra los datos reales de la base de datos. El esquema puede ser una sola tabla o puede tener más de una tabla relacionada. El esquema representa la relación entre estas tablas. La fase inicial del diseño de la base de datos es caracterizar completamente las necesidades de datos de los posibles usuarios de la base de datos. El diseñador de la base de datos necesita interactuar ampliamente con los expertos y los usuarios del dominio para llevar a cabo la tarea. El resultado de esta fase es una especificación de los requisitos del usuario. En la siguiente fase, el diseñador elige un modelo de datos y, aplicando los conceptos del modelo de datos elegido, traduce estos requisitos en un esquema conceptual de la base de datos. El esquema desarrollado en esta fase de diseño conceptual proporciona una descripción detallada de la empresa. El modelo ER se utiliza normalmente para representar el diseño conceptual. El esquema conceptual especifica las entidades que están representadas en la base de datos, los atributos de las entidades, las relaciones entre las entidades y las restricciones sobre las entidades. La fase de diseño conceptual da como resultado la creación de un diagrama entidad-relación que proporciona una representación gráfica del esquema. El diseñador revisa el esquema para confirmar que todos los requisitos de datos están efectivamente satisfechos y no están en conflicto entre sí. Un esquema conceptual completamente desarrollado indicó los requisitos funcionales de la empresa. En una especificación de requisitos funcionales, los usuarios describen los tipos de operaciones o transacciones que se realizarán en los datos. Ejemplos: modificar y actualizar los datos buscando y recuperando datos específicos. En esta etapa del diseño conceptual, el diseñador puede revisar el esquema para asegurarse de que cumpla con los requisitos funcionales. Las tareas para realizar en el esquema conceptual son las siguientes: 1. Identificar las entidades. 2. Identificar las relaciones. 3. Identificar los atributos y asociarlos a entidades y relaciones. 4. Determinar los dominios de los atributos. 42 5. Determinar los identificadores. 6. Determinar las jerarquías de generalización (si las hay). 7. Dibujar el diagrama ER. 8. Revisar el esquema conceptual local con el usuario. 4.1 Esquema conceptual: de alto nivel, detallado El esquema conceptual de alto nivel es una descripción general simplificada y detallada del proceso de diseño de la base de datos. El primer paso que se realiza es la recopilación y el análisis de requisitos (Museros & Sanz, 2010). Durante este paso, los diseñadores de la base de datos entrevistan a los posibles usuarios de la base de datos para comprender y documentar sus requisitos de datos. El resultado de este paso es un conjunto de requisitos de los usuarios escrito de forma concisa. Estos requisitos deben especificarse de la forma más detallada y completa posible. Paralelamente a la especificación de los requisitos de datos, es útil especificar los requisitos funcionales conocidos de la aplicación. Estos consisten en las operaciones (o transacciones) definidas por el usuario que se aplicarán a la base de datos, incluidas tanto las recuperaciones como las actualizaciones. En el diseño de software, es común utilizar diagramas de flujo de datos, diagramas de secuencia, escenarios y otras técnicas para especificar requisitos funcionales. No discutiremos ninguna de estas técnicas aquí ya que generalmente se describen en detalle en ingeniería de software. Una vez recopilados y analizados los requisitos, el siguiente paso es crear un esquema conceptual para la base de datos, utilizando un modelo de datos conceptual de alto nivel. Este paso se llama diseño conceptual. El esquema conceptual es una descripción concisa de los requisitos de datos de los usuarios e incluye descripciones detalladas de los tipos de entidad, relaciones y restricciones; estos se expresan utilizando los conceptos proporcionados por el modelo de datos de alto nivel. Debido a que estos conceptos no incluyen detalles de implementación, generalmente son más fáciles de entender y pueden usarse para comunicarse con usuarios no técnicos. El esquema conceptual de alto nivel también se puede utilizar como referencia para garantizar que se cumplan todos los requisitos de datos de los usuarios y que los requisitos no entren en conflicto. Este enfoque permite a los diseñadores de bases de datos concentrarse en especificar las propiedades de los datos, sin preocuparse por los detalles de almacenamiento e implementación. Esto facilita la creación de un buen diseño de base de datos conceptual. El objetivo de esta etapa es elaborar un modelo conceptual del problema. Este modelo se representa mediante algún modelo de datos de alto nivel. Uno de los modelos más conocidos es el modelo entidad-relación (ER). 43 Durante o después del diseño del esquema conceptual, las operaciones básicas del modelo de datos se pueden utilizar para especificar las consultas y operaciones de los usuarios de alto nivel identificadas durante el análisis funcional. Esto también sirve para confirmar que el esquema conceptual cumple con todos los requisitos funcionales identificados. Se pueden introducir modificaciones al esquema conceptual si algunos requisitos funcionales no se pueden especificar utilizando el esquema inicial. Un esquema de datos conceptual identifica las relaciones de más alto nivel entre las diferentes entidades. Las características del esquema de datos conceptuales incluyen: • Incluye las entidades importantes y las relaciones entre ellas. • No se especifica ningún atributo. • No se especifica ninguna clave principal. Figura 32. Modelo de esquema conceptual. En la Figura 32, podemos ver que la única información que se muestra a través del modelo de datos conceptual son las entidades que describen los datos y las relaciones entre esas entidades. No se muestra ninguna otra información a través del modelo de datos conceptual. 4.2 Relaciones redundantes A veces, en los modelos ER va a existir una relación redundante. Son relaciones que ya están indicadas por otras relaciones, aunque no directamente. Por ejemplo, En la Figura 33, 44 si todos los empleados pertenecen a un servicio y todos los servicios a un departamento, la asociación directa de Departamento y Empleado es redundante y por tanto habría que eliminarla. Sin embargo, si se da la especificación o requisito de usuario de que un empleado puede trabajar en un departamento sin pertenecer a ningún servicio, esta asociación no será redundante. Figura 33. Ejemplo de relaciones que pueden ser o no redundantes. Hay que entender que las relaciones redundantes se replican en un sinnúmero de oportunidades de forma consecutiva. Si se desea eliminar una tabla o dato que se encuentren bajo una relación con este tipo de comportamientos no se corre el peligro de perder el vínculo que ha sido establecido en la tabla. 4.3 Transformación de relaciones M:N Las relaciones M:N añaden complejidad y confusión a un modelo de base de datos y al proceso de desarrollo de la aplicación. La clave para resolver las relaciones M:N es separar las dos entidades y crear dos relaciones de uno a muchos (1:M) entre ellas con una tercera entidad de intersección. La entidad de intersección generalmente contiene atributos de ambas entidades conectadas. 45 Un tipo de relación M:N se transforma en una tabla que tendrá como clave primaria la concatenación de las claves primarias de los tipos de entidades que asocia. Para cada relación M:N se crea una tabla que tiene como clave primaria la combinación de los atributos clave de cada una de las entidades participantes. A esta tabla se le incluye cualquier tipo de atributo de la relación. La nueva tabla tiene la finalidad de crear una referencia cruzada entre las claves primarias. Es por este motivo que a este tipo de tablas se las denomina tablas de relaciones o referencias cruzadas. PROFESOR Cod_prof (M:N) IMPARTE (M:N) Modelo Relacional PROFESOR ( Cod_prof, ….. ) CURSO ( Cod_curso ) IMPARTE ( Cod_curso, Cod_prof ) CURSO Cod_curso Figura 34. Transformación de relaciones muchos a muchos. 4.4 Esquema lógico de datos Un esquema lógico de una base de datos, es una descripción de la estructura de la base de datos que puede procesar un SGBD. El propósito del esquema de datos lógicos es comprender la información recibida, almacenada y transmitida por un sistema. En el contexto de esta especificación de captura del sistema, es para comprender y caracterizar los datos y los flujos que cruzan los límites del sistema para solidificar conceptualmente las interfaces que un sistema proporciona o requiere. Un esquema de datos lógicos se basa en la mayoría de los casos en un esquema de datos conceptual que, con el uso de ciertas pautas y reglas, se transforma en un esquema relacional (modelo). Un esquema de datos lógicos describe los datos con el mayor detalle posible, sin importar cómo se implementarán físicamente en la base de datos. Las características de un esquema de datos lógicos son: • Incluye todas las entidades y relaciones entre ellas • Se especifican todos los atributos de cada entidad • Se especifica la clave principal para cada entidad • Se especifican claves externas (claves que identifican la relación entre diferentes entidades). 46 • La normalización ocurre en este nivel. Los pasos para diseñar el esquema de datos lógicos son los siguientes: • Especificar claves primarias para todas las entidades • Encontrar las relaciones entre diferentes entidades • Encontrar todos los atributos de cada entidad • Resolver las relaciones M:N • Normalización Figura 35. Modelo de esquema lógico. En la Figura 35, CP significa clave primaria y CF clave foránea. Las principales diferencias del esquema de datos conceptual y lógico son: • En un modelo de datos lógicos, las claves primarias están claramente presente, mientras que en un modelo de datos conceptual no se incluyen claves primerias. • En un modelo de datos lógicos, se deben incluir todos los atributos específicos dentro de una entidad, mientras que en un modelo de datos conceptual no. • Las relaciones entre entidades se especifican mediante claves primarias y claves foráneas en un modelo de datos lógicos. En un modelo de datos conceptual, las relaciones simplemente se establecen, no se especifican, por lo que simplemente 47 sabemos que dos entidades están relacionadas, pero no especificamos qué atributos se utilizan para esta relación. 4.5 Pautas para transformar un esquema conceptual a un esquema lógico relacional El objetivo del diseño lógico es construir un esquema relacional que representa correcta y eficientemente toda la información descrita por un esquema ER producido durante la fase de diseño conceptual. Este proceso no es solo una simple transformación de un modelo a otro por dos razones principales: • No todos los constructos del modelo ER pueden ser transformado naturalmente al modelo relacional • El esquema debe reestructurarse de tal manera que la ejecución de las operaciones proyectadas de la manera más eficiente posible. Las reglas básicas para convertir un esquema conceptual a un esquema lógico relacional son las siguientes: • Eliminación de atributos múltiples: Todos los atributos múltiples se deben transformar en un tipo de entidad débil por existencia con una relación de M:N o de 1:M, según sea el caso, con el tipo de entidad sobre el cual estaba definido. Si se considera que la nueva entidad creada resulta ambigua, se le pueden añadir atributos o heredarlos de la otra entidad. Suponemos para el siguiente ejemplo que una persona puede tener varios números de teléfono: Figura 36. Ejemplo de atributos múltiples. En este caso ser a necesario expresar el esquema relacional de la forma: PERSONA ( ... lista de atributos ...) 48 TELEFONO(idPersona*, numero, tipo) • Eliminación de atributos compuestos: Todos los atributos compuestos deben ser descompuestos en atributos simples que quedan asociados a la misma entidad. Por ejemplo: Figura 37. Ejemplo de atributos compuestos. Se expresaría mediante el siguiente esquema relacional: PERSONA (DNI, nombre, apellido1, apellido2, peso) • Transformación de entidades fuertes: En principio las entidades fuertes del modelo ER son transformadas siguiendo estas instrucciones: o Las entidades pasan a ser tablas. o Los atributos pasan a ser columnas. o Los identificadores principales pasan a ser claves primarias. o Los identificadores candidatos pasan a ser claves candidatas. Esto hace que la transformación se produzca según este ejemplo: Figura 38. Ejemplo de transformaciones de entidades fuertes. 49 • Transformación de relaciones: La idea inicial es transformar cada relación en una tabla, pero hay que distinguir según el tipo de relación. o Relación varios a varios: La relación se transforma en una tabla cuyos atributos son: los atributos de la relación y las claves de las entidades relacionadas, que pasarán a ser claves externas. La clave de la tabla la forman todas las claves externas. Figura 39. Ejemplo de transformación de relación varios a varios. o Relación uno a varios o uno a uno: La relación de tipo uno a varios no requiere ser transformadas en una tabla en el modelo relacional. En su lugar la tabla del lado varios (tabla relacionada) incluye como clave externa el identificador de la entidad del lado uno (tabla principal). En el caso de que el número mínimo de la relación sea de cero (puede haber ejemplares de la entidad uno sin relacionar), se deberá permitir valores nulos en la clave externa identificador2. En otro caso no se podrán permitir, ya que siempre habrá un valor relacionado. Figura 40. Ejemplo de transformación de relación uno a varios o uno a uno. 50 En el caso de las relaciones uno a uno, ocurre lo mismo: la relación no se convierte en tabla, sino que se coloca en una de las tablas (en principio daría igual cuál) el identificador de la entidad relacionada como clave externa. En el caso de que una entidad participe opcionalmente en la relación, entonces es el identificador de esta el que se colocará como clave externa en la tabla que representa a la otra entidad. o Relaciones reflexivas: Las relaciones reflexivas o recursivas se tratan de la misma forma que las otras, sólo que un mismo atributo puede figurar dos veces en una tabla como resultado de la transformación. Figura 41. Ejemplo de transformación de relación reflexiva o recursiva. • Transformación de entidades débiles: Toda entidad débil incorpora una relación implícita con una entidad fuerte. Esta relación no necesita incorporarse como tabla en el modelo relacional. Si se necesita incorporar la clave de la entidad fuerte como clave externa en la entidad débil. Es más, normalmente esa clave externa forma parte de la clave principal de la tabla que representa a la entidad débil. En ocasiones el identificador de la entidad débil es suficiente para identificar los ejemplares de dicha entidad, entonces ese identificador quedaría como clave principal, pero el identificador de la entidad fuerte seguiría figurando como clave externa en la entidad débil. 51 Figura 42. Ejemplo de transformación de entidades débiles. 4.6 Modelo relacional. Tablas y sus características: Filas, columnas Una tabla se percibe como una estructura bidimensional compuesta por filas y columnas. En una tabla se guardan los datos recogidos por un SGBD y su estructura general se asemeja a la vista general de programas de hojas de cálculo. Una tabla también se llama relación porque el creador del modelo relacional, E. F. Codd, usó el término relación como sinónimo de tabla. Una tabla es el componente principal en el modelo de datos relacionales. Las características de una tabla relacional se resumen a continuación: • Una tabla se percibe como una estructura bidimensional compuesta de filas y columnas. • Cada fila de la tabla (tupla) representa una ocurrencia de entidad única dentro del conjunto de entidades. • Cada columna de la tabla representa un atributo y cada columna tiene un nombre distinto. • Cada intersección de fila / columna representa un valor de datos único. • Todos los valores de una columna deben ajustarse al mismo formato de datos. • Cada columna tiene un rango específico de valores conocido como dominio de atributo. • El orden de las filas y columnas es irrelevante para el SGBD. • Cada tabla debe tener un atributo o una combinación de atributos que identifique de forma única cada fila. 4.7 Claves: Clave candidata, superclave, clave primaria, clave foránea Una clave en un SGBD es un atributo o un conjunto de atributos que ayudan a identificar de forma única una tupla en una tabla. Las claves también se utilizan para 52 establecer relaciones entre las diferentes tablas y columnas de una base de datos relacional. Una clave se utiliza en las definiciones de varios tipos de restricciones de integridad. Una tabla en una base de datos representa una colección de registros o eventos para una relación en particular. Ahora puede haber miles y miles de esos registros, algunos de los cuales pueden estar duplicados. Entonces, debe haber una forma de identificar cada registro por separado y de forma única, es decir, sin duplicados y para eso se usan las claves en un SGBD. Tomemos un ejemplo de la vida real de la base de datos de cada estudiante que estudia en una escuela de ingeniería. ¿Qué atributo del estudiante van a identificar de manera única a cada uno de ellos? Se puede referir a un estudiante usando su nombre, departamento, año y sección. O bien, puede mencionar solo el número de registro universitario del estudiante, y puede obtener todos los demás detalles del estudiante. Una clave puede ser una combinación de uno o más de un atributo. El motivo principal de esto es darle a cada registro una identidad única. • Clave candidata: Conjunto de atributos que identifican unívocamente cada tupla de la relación. Es decir, columnas cuyos valores no se repiten para esa tabla. Figura 43. Ejemplo de claves candidatas. • Superclave: Una superclave es un conjunto de uno o más atributos que, tomados colectivamente, permiten identificar de forma única una entidad en el conjunto de entidades. Esto significa que todas aquellas columnas de una tabla que sean capaces de identificar las otras columnas de esa tabla de forma única se considerarán superclaves. 53 Figura 44. Ejemplo de una superclave. • Clave primaria: Es la clave candidata que se escoge como identificador de las tuplas. Se elige clave primaria a la clave candidata que identifique mejor a cada tupla en el contexto de la base de datos. Por ejemplo, un campo con la cédula de identidad sería clave candidata de una tabla de clientes. Aunque, si en esa relación existe un campo de código de cliente, este sería mejor candidato para clave principal, porque es mejor identificador para ese contexto. En el caso de la Figura 44, la clave primaria sería Id_cliente. • Clave alternativa: Es cualquier clave candidata que no sea primaria. En el ejemplo de la Figura 44 sería Nombre, Teléfono y No_IFE. • Clave foránea: Se utiliza para establecer relaciones entre dos tablas. Una clave externa requerirá que cada valor de una columna o conjunto de columnas coincida con la clave principal de la tabla de referencia. Las claves externas ayudan a mantener los datos y la integridad referencial. 4.8 Reglas de Codd E.F Codd fue un informático que inventó el modelo relacional para la gestión de bases de datos. Codd propuso 13 reglas conocidas popularmente como las 12 reglas de Codd para probar el concepto de SGBD contra su modelo relacional (las reglas empiezan por la Regla cero). La regla de Codd actualmente define qué calidad requiere un SGBD para convertirse en un SGBDR. Hasta ahora, casi no hay ningún producto comercial que siga las 13 reglas de Codd. Incluso Oracle tiene ocho y medio (8.5) de trece. Las reglas de Codd son las siguientes: 1. Regla cero: Regla de fundación: Esta regla establece que para que un sistema califique como SGBDR, debe poder administrar la base de datos por completo a través de las capacidades relacionales. 54 2. Regla 1: Regla de información: Toda la información (incluidos los metadatos) debe representarse como datos almacenados en celdas de tablas. Las filas y columnas deben estar estrictamente desordenadas. 3. Regla 2: Regla de acceso garantizado: Cada dato único (valor atómico) debe ser accesible por: Nombre de la tabla + Clave principal (Fila) + Atributo (columna). NOTA: La posibilidad de acceder directamente a través de POINTER es una violación de esta regla. 4. Regla 3: Regla de tratamiento sistemático de NULL: NULL tiene varios significados, puede significar datos faltantes, no aplicable o sin valor. Debe manejarse de manera consistente. Además, la clave principal nunca debe ser nula. La expresión en NULL debe dar un valor nulo. 5. Regla 4: Catálogo dinámico en línea: El diccionario de la base de datos (catálogo) es la descripción de la estructura de la base de datos completa y debe almacenarse en línea. El catálogo debe regirse por las mismas reglas que el resto de la base de datos. Se debe usar el mismo lenguaje de consulta en el catálogo que se usa para consultar la base de datos. 6. Regla 5: Lenguaje potente y bien estructurado: Debe existir un lenguaje bien estructurado para proporcionar todas las formas de acceso a los datos almacenados en la base de datos, como por ejemplo el SQL. Si la base de datos permite el acceso a los datos sin el uso de este lenguaje, entonces represente una violación. 7. Regla 6: Regla de actualización de vistas: Todas las vistas que son teóricamente actualizables también deben serlo por el sistema. 8. Regla 7: Operación a nivel relacional: Debe haber operaciones para Insertar, Eliminar, Actualizar en cada nivel de relaciones. También se deben admitir operaciones de configuración como Unión, Intersección y borrados. 9. Regla 8: Independencia físico de datos: El almacenamiento físico de datos no debería importarle al sistema. Si, por ejemplo, se cambia el nombre de alguna tabla de soporte de archivos o se mueve de un disco a otro, no debería afectar la aplicación. 10. Regla 9: Independencia lógica de datos: Si hay un cambio en la estructura lógica (estructuras de tabla) de la base de datos, la vista de los datos por parte del usuario no debería cambiar. Digamos, si una tabla se divide en dos tablas, una nueva vista debería dar como resultado la unión de las dos tablas. Esta regla es muy difícil de cumplir. 11. Regla 10: Independencia de la integridad: La base de datos debe hacer cumplir su propia integridad en lugar de utilizar otros programas. Las restricciones de clave y verificación, disparadores, etc. deben almacenarse en el diccionario de datos. Esto también hace que SGBDR sea independiente de las interfaces existentes. 55 12. Regla 11: Independencia de distribución: Una base de datos debería funcionar de forma correcta, independientemente de su distribución en una red. Incluso si una base de datos está distribuida geográficamente, con datos almacenados en diferentes partes, el usuario final debe tener la impresión de que está almacenada en el mismo lugar. Esto sienta las bases de una base de datos distribuida. 13. Regla 12: Regla de no subversión: Si se permite el acceso de bajo nivel a un sistema, no debería poder subvertir o eludir las reglas de integridad para cambiar los datos. Esto se puede lograr mediante algún tipo de búsqueda o cifrado. 4.9 Diccionario de datos. Tipos de datos. Instancia de base de datos Un diccionario de datos contiene metadatos. Es decir, datos sobre la base de datos. El diccionario de datos es muy importante ya que contiene información como qué hay en la base de datos, quién puede acceder a él O dónde está almacenada físicamente la base de datos. Los usuarios de la base de datos normalmente no interactúan con el diccionario de datos ya que es sólo manejado por los administradores de la base de datos. El diccionario de datos en general contiene información sobre lo siguiente: • Nombres de todas las tablas de la base de datos y sus esquemas. • Detalles sobre todas las tablas de la base de datos, como sus propietarios, sus restricciones de seguridad, cuándo se crearon, etc. • Información física sobre las tablas y cómo y dónde se almacenan. • Restricciones de la tabla, como atributos de clave primaria, información de clave foránea, etc. • Información sobre las vistas de la base de datos que son visibles. ¿Por qué utilizar un diccionario de datos? Los diccionarios de datos son útiles por varias razones. En resumen, ellos: • Ayudar a evitar inconsistencias de datos en un proyecto. • Ayudar a definir las convenciones que se utilizarán en un proyecto. • Proporcionar coherencia en la recopilación y el uso de datos entre varios miembros de un equipo. • Facilite el análisis de los datos • Hace cumplir el uso de estándares de datos 56 ¿Qué son los estándares de datos y por qué debería utilizarlos? Los estándares de datos son reglas que rigen la forma en que se recopilan, registran y representan los datos. Los estándares proporcionan una referencia comúnmente entendida para la interpretación y el uso de conjuntos de datos. Al utilizar estándares, los miembros de un equipo sabrán que la forma en que se recopilan y describen sus datos será la misma en los diferentes proyectos. El uso de estándares de datos como parte de un diccionario de datos bien elaborado puede ayudar a aumentar la usabilidad de los datos y garantizará que los datos sean reconocibles y utilizables. Tipos de datos en bases de datos Un dato permite describir un objeto. Dicho objeto puede ser una entidad, por ejemplo, una casa en la que viven personas. La casa es la entidad y la cantidad de personas que viven en la casa son un dato, que en este caso es numérico. Pueden existir diversos tipos de datos dentro de una base de datos como: • Entero o integer: Es un número entero que puede tener un valor positivo, negativo o cero. No puede ser una fracción ni puede tener decimales. Se usa comúnmente en programación. La suma, resta y multiplicación de dos números enteros da como resultado un número entero. Pero la división de dos números enteros puede resultar en un número entero o decimal. El decimal resultante se puede redondear o truncar para producir un número entero. • Caracter o char: Se refiere a cualquier número, letra, espacio o símbolo que se puede ingresar en una computadora. Cada carácter ocupa un byte de espacio. • Cadena de caracteres o string: Se utiliza para representar un texto. Está compuesto por un conjunto de caracteres que pueden tener espacios y números. Las cadenas se incluyen entre comillas para identificar los datos como una cadena y no como un nombre de variable ni un número. • Número de coma flotante o float: Es un número que contiene decimales. Los números que contienen fracciones también se consideran números de coma flotante. • Matriz o array: Contiene un grupo de elementos que pueden ser del mismo tipo de datos, como un número entero o una cadena. Se utiliza para organizar los datos para facilitar la clasificación y la búsqueda de conjuntos de valores relacionados. • Varchar: como su nombre lo indica, es un carácter variable ya que el almacenamiento de memoria tiene una longitud variable. Cada carácter ocupa un byte de espacio más 2 bytes para la información de longitud. Nota: Utilice Caracter 57 para entradas de datos con longitud fija, como el número de teléfono. Utilice Varchar para entradas de datos con longitud variable, como la dirección. • Booleano: se utiliza para crear declaraciones verdaderas o falsas. Para comparar valores se utilizan los siguientes operadores: AND, OR, XOR y NOT. • Fecha y hora: Estos tipos de datos se utilizan para trabajar con datos que contienen fechas y horas. Instancia de base de datos En general, una instancia de base de datos describe un entorno de base de datos completo y todos sus componentes. Este sistema incluye varias partes, incluido el software del SGBDR, la estructura de la tabla, los procedimientos almacenados y otras funciones. Los administradores de bases de datos pueden crear varias instancias de la misma base de datos para diferentes propósitos. Por ejemplo, una organización con una base de datos de empleados puede tener tres instancias: • Instancias de producción: Los administradores utilizan estas instancias para contener datos en vivo. • Instancias de preproducción: Los desarrolladores utilizan instancias de preproducción para probar nuevas funciones antes de lanzar las funciones a producción. • Instancias de desarrollo: Los desarrolladores de bases de datos utilizan instancias de desarrollo para crear nuevas funciones antes de probarlas en preproducción. También puede resultar útil pensar en una instancia en contexto con un esquema de base de datos. El esquema son los metadatos que definen el diseño de la base de datos y determinan los métodos para la organización de los datos. Incluye las tablas de una base de datos y sus columnas y las reglas que gobiernan los datos. Por ejemplo, una tabla de empleados en una base de datos puede tener columnas para el nombre, la dirección, la identificación del empleado y las descripciones del puesto. Esta disposición es la estructura o esquema de la base de datos. Mientras que el esquema de la base de datos define la organización de los datos, una instancia de la base de datos es una instantánea del contenido en un momento dado. Esta imagen incluye los datos y su relación con otros datos de la base de datos en un momento determinado. 58 Lectura complementaria de la asignatura: • Gómez, Á. P., Jalca, J. J. R., García, J. G., Sánchez, O. Q., Parrales, K. M., & Merino, J. M. (2017). Fundamentos sobre la gestión de base de datos (Vol. 23). • Beynon-Davies, P. (2018). Sistemas de bases de datos. Reverté. Referencias: Beynon-Davies, P. (2018). Sistemas de bases de datos. Reverté. Boggiano-Castillo, M. B., Pereira, A., Pérez, A., González-González, L.-M., & Pérez-Vázquez, R. (2013). Inserción automática de reglas de negocio en bases de datos. Revista Técnica de La Facultad de Ingeniería Universidad Del Zulia, 36(3), 253–261. Castillo Arrojo, Y. (2018). Diseño de una base de datos aplicada al proceso de tramitación en Planificación Física Ranchuelo. Universidad Central ‘“Marta Abreu”’de Las Villas. Facultad de Ingeniería …. Cobo, Á. (2007). Diseño y programación de bases de datos. Visión Libros. Elmasri, R., Navathe, S. B., Castillo, V. C., Pérez, G. Z., & Espiga, B. G. (2002). Fundamentos de sistemas de bases de datos (Issue QA76. 9D3 E553 2007.). Addison-Wesley. Museros, L., & Sanz, I. (2010). Tema 8: Diseño Lógico de Bases de Datos Relacionales. Ordoñez, M. Z., Tapia, J. H., & Asanza, W. R. (2016). Fundamentos de base de datos. Machala: Ecuador. Pereira Toledo, A., Rodríguez Morffi, A., Pérez Alonso, A., & González González, L. M. (2020). Un enfoque ER/SBVR para la modelación conceptual en bases de datos de restricciones de integridad. Revista Cubana de Ciencias Informáticas, 14(4), 48–66. Sánchez, J. (2004). Diseño conceptual de bases de datos. Creative Commons. 59 Sánchez Romero, C. R., & Villacis Miranda, S. P. (2020). Análisis, diseño y desarrollo de prototipo funcional de un intérprete para la transformación y ejecución de un lenguaje natural escrito a sentencias SQL. PUCE-Quito. 60