MODELO ENTIDAD-RELACIÓN
El modelo de datos de entidad-relación
(ER) se basa en una percepción de un mundo real que consiste en un conjunto de
objetos básicos llamados entidades y de relaciones entre estos objetos. Se
desarrolló para facilitar el diseño de bases de datos permitiendo especificar un
esquema empresarial. Este esquema representa la estructura lógica general de la
base de datos.
Objetos
básicos del modelo ER
Los conceptos básicos previstos por el
modelo ER son entidades, relaciones y atributos.
· Entidades y conjunto de entidades
Una entidad es un objeto que existe y puede distinguirse de otros
objetos. La entidad puede ser concreta, por ejemplo: una persona o un libro; o
abstracta, por ejemplo un día festivo o un concepto.
Un conjunto de entidades es un grupo de entidades del mismo tipo.
El conjunto de
todas las personas que tienen una
cuenta en el banco, por ejemplo, puede definirse como el conjunto de entidades
clientes.
Una entidad está representada por un
conjunto de atributos. Los
posibles atributos del conjunto de entidades clientes son nombre, documento,
calle y ciudad. Para cada atributo existe un rango de valores permitidos,
llamado dominio del atributo.
El dominio del atributo nombre podría ser el conjunto de todas los nombres de
personas de cierta longitud.
. Relaciones
y conjunto de relaciones
Una relación es una asociación entre varias entidades. Por ejemplo
es posible definir una relación que asocia al cliente Gutiérrez con la cuenta
401.
Un conjunto de relaciones es un grupo de relaciones del mismo
tipo. Se definirá el
conjunto de relaciones clientecuenta
para denotar la asociación entre los clientes y las cuentas bancarias que
tienen.
La relación clientecuenta es un
ejemplo de una relación binaria,
es decir, una que implica a dos conjuntos de entidades.
Existen conjuntos de relaciones que
incluyen a n-conjuntos de entidades, relaciones
narias, por ejemplo las relaciones tenaria cliecuentasuc que
especifica que el cliente Gutiérrez
tienen la cuenta 401 en la surcusal
Córdoba.
Los relaciones recursivas son relaciones binarias que conectan una
entidad consigo misma. Una relación también puede tener atributos descriptivos o rótulos.
Por ejemplo, fecha podría ser un atributo del conjunto de relaciones
clientecuenta. Esto especifica la última fecha en que el cliente tuvo acceso a
su cuenta.
· Cardinalidades de mapeo
Un esquema ER empresarial puede
definir ciertas limitantes con las que deben cumplir los datos contenidos en la
base de datos. Una limitante importante es la de las cardinalidades de
mapeo que expresan el número de entidades con las que puede
asociarse otra entidad mediante una relación.
Las cardinalidades de mapeo son más
útiles al describir conjuntos binarios de
relaciones, aunque también son
aplicables a conjuntos n-arios de relaciones.
Para un conjunto binario de relaciones
R entre los conjuntos de entidades A y B, la
cardinalidad de mapeo puede ser:
Una a una: una entidad de A
está asociada únicamente con una entidad de B y una entidad de B está asociada
solo con una entidad de A.
A B
Una a muchas: una entidad en A
está asociada con varias entidades de B, pero
una entidad de B puede asociarse
únicamente con una entidad de A.
Muchas a una: una entidad de A
está asociada únicamente con una entidad en B,
pero una entidad de B está relacionada
con varias entidades de A.
Muchas a muchas: una entidad en A
está asociada con varias entidades de B y
una entidad en B está vinculada con
varias entidades de A.
Llaves primarias
Una tarea muy importante dentro de la
modelación de bases de datos consiste en especificar cómo se van a distinguir
las entidades y las relaciones. Conceptualment , las entidades individuales y
las relaciones son distintas entre sí, pero desde el punto de vista de una base
de datos la diferencia entre ellas debe expresarse en términos de sus
atributos. Para hacer estas distinciones, se asigna una llave primaria a cada conjunto de
entidades, esta, es un conjunto de uno o más atributos que, juntos, permiten
identificar en forma única a una entidad dentro del conjunto de entidades. Por
ejemplo: el atributo documento del conjunto entidades cliente es suficiente
para distinguir a una entidad cliente de otra, por lo tanto puede ser la llave primara
de ese conjunto de entidades.
Rectángulos: representan
conjuntos de entidades.
. Elipses: representan
atributos.
. Rombos: representa conjuntos
de relaciones.
. Líneas: conectan los
atributos a los conjuntos de entidades, y los conjuntos de
entidades a los conjuntos de
relaciones.
MODELO RELACIONAL
Su idea fundamental es el uso de «relaciones». Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados «tuplas». Pese a que ésta es la teoría de las bases de datos relacionales creadas por Edgar Frank Codd, la mayoría de las veces se conceptualiza de una manera más fácil de imaginar, esto es, pensando en cada relación como si fuese una tabla que está compuesta por registros (cada fila de la tabla sería un registro o tupla), y columnas (también llamadas campos).
En este modelo todos los datos
son almacenados en relaciones, y como cada relación es un conjunto de datos, el
orden en el que éstos se almacenen no tiene relevancia (a diferencia de otros
modelos como el jerárquico y el de red). Esto tiene la
considerable ventaja de que es más fácil de entender y de utilizar por un
usuario no experto. La información puede ser recuperada o almacenada por medio
de consultas que ofrecen una amplia flexibilidad y poder para administrar la
información.
Este modelo considera la base de datos como una colección de relaciones. De manera
simple, una relación representa una tabla que no es más que un conjunto de
filas, cada fila es un conjunto de campos y cada campo representa un valor que
interpretado describe el mundo real. Cada fila también se puede denominar tupla
o registro y a cada columna también se le puede llamar campo o atributo.
Para manipular la información
utilizamos un lenguaje relacional, actualmente se cuenta con dos lenguajes
formales el Álgebra relacional y el Cálculo relacional. El
Álgebra relacional permite describir la forma de realizar una consulta, en
cambio, el Cálculo relacional sólo indica lo que se desea devolver.
Esquema
Un esquema es la definición de
una estructura (generalmente relaciones o tablas de una base de datos), es
decir, determina la identidad de la relación y que tipo de información podrá
ser almacenada dentro de ella; en otras palabras, el esquema son los metadatos de la relación. Todo esquema constará de:
- Nombre de la relación (su identificador).
- Nombre de los atributos (o campos) de la
relación y sus dominios; el dominio de un atributo o campo define los
valores permitidos para el mismo, es equivalente al tipo de dato por
ejemplo character, integer, date, string,
etc.
Instancias
Una instancia de manera formal
es la aplicación de un esquema a un conjunto finito de datos. En palabras no
tan técnicas, se puede definir como el contenido de una tabla en un momento
dado, pero también es valido referirnos a una instancia cuando trabajamos o
mostramos únicamente un subconjunto de la información contenida en una relación
o tabla, como por ejemplo:
- Ciertos caracteres y números (una sola
columna de una sola fila).
- Algunas o todas las filas con todas o
algunas columnas
·
Cada fila es una tupla. El número de filas es llamado cardinalidad.
MODELO JERÁRQUICO
Un modelo de datos jerárquico
es un modelo de datos en el cual los datos son organizados en una estructura
parecida a un árbol. La estructura permite a la información que repite y usa
relaciones padre/Hijo: cada padre puede tener muchos hijos pero cada hijo sólo
tiene un padre. Todos los atributos de un registro específico son catalogados
bajo un tipo de entidad.
Ejemplo de un Modelo Jerárquico:
En una base de datos, un tipo de entidad es el equivalente de una tabla;
cada registro individual es representado como una fila y un atributo como una
columna. Los tipos de entidad son relacionados el uno con el otro usando 1:
Trazar un mapa de n, también conocido como relacion de uno a varios. El ejemplo
más aprobado de base de datos
jerárquica modela es un IMS diseñado por la IBM.
El modelo de datos jerárquico
presenta importante inconvenientes, que provienen principalmente de su rigidez,
la cual deriva de la falta de capacidad de las organizaciones jerárquicas para representar sin redundancias
ciertas estructuras muy difundidas en la realidad, como son las interrelaciones
reflexivas y N:M.
La poca flexibilidad de este modelo
puede obligar a la introducción de redundancias cuando es preciso
instrumentar, mediante el modelo jerárquico, situaciones del mundo real que no
responden a una jerarquía; así ocurre con el esquema no jerárquico de la figura
10 cuando se quiere adaptar al modelo jerárquico, donde es preciso crear dos
árboles e introducir redundancias, ya que los registros D, H e I aparecen en
ambas jerarquías. Se trata de una pobre solución de diseño.
Se puede calcular un índice de
redundancia mediante
Ir -?N?. Nodos extra x 100
N?. Total de nodos
En nuestro caso, el índice de
redundancia se calcularía como
Ir -?3 x 100 -?20%
La redundancia que hemos calculado
es una redundancia lógica que, en general, no coincide con la
redundancia física. Esto es debido a que al almacenar los
datos en el dispositivo físico no se suelen repetir los registros completos,
sino sólo los identificadores, o bien se introducen punteros.
En general, los productos ofrecen
algún tipo de solución a estos problemas.
Otra limitación importante del
modelo jerárquico es no estar preparado para representar interrelaciones N:M,
como la existente entre profesores y alumnos.
Además del grave problema que
provocan estas redundancias no controladas por el sistema, existe otro importante inconveniente en este tipo de
solución como es la no conservación de las simetrías naturales existentes en el
mundo real.
Las actualizaciones en las bases de
datos jerárquicas pueden también originar problemas, debido a las restricciones
inherentes al modelo:
- Toda alta, a no ser que
corresponda a un nodo raíz, debe tener un padre. Por ejemplo, sería imposible
insertar en la base de datos de un alumno que aún no tuviera asignado profesor.
Se podría resolver el problema
creando un padre ficticio para este registro, pero con ello se complicaría la
labor del usuario de la base de datos, que tendría, cuando deseara conectar el
registro a su padre real, que eliminarlo de la base de datos y volver a
introducirlo ligado a su verdadero padre Además, el sistema no podría
distinguir entre padre ficticio y real y cuando contara el número de profesores
de la base de datos nos daría uno más.
- La baja de un registro implica que
desaparezca todo el subárbol que tiene dicho registro como nodo raíz, con lo
que pueden desaparecer datos importantes que convendría conservar en la base de
datos
No hay comentarios:
Publicar un comentario