Resumen
1.
Claves:
En lo que son las claves es necesario tener forma de
especificación de entidades dentro de las propias entidades ya que esto
conlleva a las relaciones dentro de un
conjunto que a las vez dado son
distinguibles. En lo que es las
entidades de relación o ya sea de sus diferencias estas mismas se deben
expresar dentro de lo que son sus atributos ya que estas a la vez tienen
términos que los atribuye esto desde la perspectiva de la Base de Datos. Dentro
de las entidades nos permiten que tengan el mismo valor dentro de sus
atributos, al igual que las claves hay atributos que se distingan entre ellas.
- Conjunto de Entidades:
Dentro a lo que se llama superclave
habla de los atributos que se toman y se permiten identificar, ejemplos de los
mismos podría ser como atributo id-clientes donde clientes se pueda
distinguir la entidad, lo que es referente a esto es nombre-cliente ya que los atributos de esto se pueden repetir.
La superclave puede contener atributos innecesarios y tales las
superclaves mínimas se les llama claves candidatas, de lo que embase anterior nombre-cliente si se le agrega calle este tipo de conjuntos [nombre-cliente, calle-cliente] son
claves candidatas, y lo que no serian son [id-cliente
y nombre-cliente] ya que los dos son entidades cliente, id-cliente es una clave candidata.
El termino clave primaria es la más común para diseñadores de Bases de
Datos para identificar entidades, la clave (primaria, candidata y superclave)
son más conocidas como entidades y a las ves esta se deben designar con cuidado
un ejemplo es de que los nombre no es suficiente dentro de una instancia de
trabajo ya que es para tener identificadores únicos lo cual también sería
conveniente tener otras claves para esta. Las claves primarias son aquellas que
deben ser estables para una persona ano es algo que varié por lo cual esto no
será algo útil para la ubicación de esta o para un buen funcionamiento dentro
de una empresa ya que las claves primarias deben ser algo que no cambie (que
sea fijo).
- Conjuntos de Relaciones:
Con lo ya presentado la clave primaria son claves únicos y que
cada conjunto de entidades participa solo una vez en la relación, si el
conjunto de relación R no tiene
atributos asociados, entonces el atributo:
-
clave-primaria (E1) U clave-primaria (E2) U clave-primaria (En).
Esto
describe relación individual R, si el conjunto R tiene tributos a entonces seria:
-
clave-primaria (E1) U clave-primaria (E2) U
clave-primaria
(En) U {a1, a2,…, am}.
Describiendo una relación
individual en el conjunto R, en ambos
casos:
-
clave-primaria (E1) U clave-primaria (E2) U
clave-primaria
(En).
En
lo que son los atributos de claves primarias no podría ser único en todos los
conjuntos de entidades ya que esto es para distinguir que el conjunto participe
solo una vez para una relación de una entidad única.
La
estructura de la clave primaria de impostor so el atributo fecha-acceso, consiste
en la unión de las claves primarias cliente y cuenta, esto ya lleva en
cuenta el uso de las claves de cómo deben ser usadas o en su forma de
aplicación para un buen uso sin tener errores o simplemente una mal orden de
todo esto.
Dentro
de esto existen también relaciones binarias esto conlleva a que el uso de la
superclave formada como se describió es clave candidata por lo tanto es clave
primaria ya que es más complicada con las restricciones de cordialidad para
considerar mas detalles que son en base a las relaciones binarias.
2.
Cuestiones de Diseño:
En
lo que es conjunto de entidades y de relación se definen en conjuntos
diferentes, esto es básico para la Base de Datos y su diseño.
-Uso
de conjuntos de Entidades o Atributos:
Dentro
de lo que son los conjuntos sus entidades debe ser una misma con atributos,
ejemplo: nombre-empleado y numero-teléfono se puede argumentar
que teléfono es una entidad por si misma con atributos, el conjunto empleado
desde un punto es:
El conjunto de entidades: empleado...
nombre-empleado y teléfono... número-teléfono y ubicación.
La relación seria: empleado-teléfono que
es la asociación que tienen.
La
diferencia principal entre esas dos definiciones al tratarse du un teléfono
como ejemplo como una entidad, los empleados puedan tener varios números que lo
asocien también podría considerarse un atributo multivalorado.
Con
el ejemplo del teléfono es solo para agregar información extra el, teléfono se
usa como una entidad más en general que un atributo así como nombre-empleado
es más como un atributo por sus cuestiones.
Los
atributos y conjuntos de entidades sus distancias de estas dependen de las
estructuras de la empresa del mundo real
que se esté modelando, los errores comunes es usar claves primarias de
entidades en vez de relación, la relación prestatario es la forma correcta de
representar la conexión entre préstamos y cliente ya que es conexión explicita,
otro erro es designar los atributos primarios como atributo de relación ya que
son más implícitos lo de relación.
-Uso
de conjuntos de Entidades o conjuntos de Relación:
No
es siempre claro expresar objetos mediante las entidades o relaciones, la
alternativa de modelar un préstamo no como entidad si no como relación de
cliente son número, préstamo e importe como atributo, en cada préstamo hay una
relación. Si los préstamos se asocian exactamente con las sucursales el diseño
seria satisfactorio con este diseño se relacionan. Sin embargo con este diseño
no se representan como las situaciones comparten un préstamo habría que
definir la relación separada y esto
tendría un cambio de modificación para numero-préstamo e importe de cada una de
etas relaciones. Estas relaciones deben ser del mismo valor para los atributos
numero-préstamo e importe ya que surgen dos problemas los datos se almacenan
varias veces y desperdician espacio de almacenamiento y la otra las actualizaciones
dejan los datos inconscientes. El asunto de evitar esto es mediante la teoría
de normalización; para determinar si se pueden usar conjuntos de entidades o de
relación es designar un conjunto de relaciones
para la descripción entre identidades.
-Conjuntos de relaciones binarias o n-arias:
Las
relaciones no binarias pueden ser representadas como binarias ya que la
relación ternaria padre que relaciona a un hijo con su padre y su madre, sin
embargo en el método, tal relación seria dos situaciones binarias padre y
madre, en este caso es preferible usar conjuntos de relaciones binarias.
Siempre
es posible reemplazar un conjunto de relaciones no binarias con diferentes
conjuntos de relación binaria, ejemplo:
• RA, relacionando E y A
• RB, relacionando E y B
• RC, relacionando E y C
En
este ejemplo se representas las relaciones de como en su método también se
entiende como binaria al asignar el conjunto de entidades, para cada relación
se crean nuevas entidades entonces cada conjunto se inserta en un nuevo
miembro, ejemplo:
• (ei,ai) en RA
• (ei,bi) en RB
• (ei,ci) en RC
Este
proceso se puede generalizar de una forma semejante a conjuntos de relación,
sin embargo no siempre es deseable.
_Este
atributo con los conjuntos de relaciones necesarios, incrementa la
complejidad del diseño.
_Un conjunto de
relaciones n-arias muestra más claramente que varias entidades
participan en una relación simple.
_en las
relaciones ternaria podría no haber una forma de restricción, esta restricción
no se puede expresar usando restricciones de carnalidad sobre los conjuntos de
relaciones RA, RB y RC.
Los conjuntos
relación se pueden dividir en relación binaria creando nuevos conjuntos de
entidades como se describió anteriormente, lo cual no sería muy natural.
-Ubicación de los
atributos de las relaciones:
La cordialidad se puede efectuar a las
situaciones de los atributos de relación estos son de uno a uno o de uno a
barios que pueden estar asociados con los conjuntos de entidades participantes
en lugar del conjunto de relación un ejemplo seria el de una cuenta x a varios
tal que la cuenta solo es única para cada usuario. Fecha-acceso registra cuando fue el ultimo ingreso a esa cuenta,
para mantener la simplicidad de los atributo de lo conjunto de entidades ya que
cada entidad cuenta participa en una
relación a lo sumo.
Los atributos de relación uno a varios se coloca
solo en el conjunto de entidad de la parte “varios”
de la relación.
La decisión de diseño donde colocar los atributos
descriptivos en tales casos como atributo de entidad, el diseñador es el que
puede elegir el modelo de mantener fecha-acceso
como un atributo impositor que es un conjunto de relación varios a
varios; entre todo esto de las relaciones se les puede llamar catálogos los
cuales interactúan y se expresan la fecha en que un cliente, fecha-acceso es un atributo del
conjunto de relación impositor, en
lugar de una de las entidades participantes. Si fecha-acceso fue un atributo de cuenta
por ejemplo no se podría determinar
No hay comentarios:
Publicar un comentario