Compendio Unidad 2 BD

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