Download En bases de datos, una entidad es la representación

Entidad
En bases de datos, una entidad es la representación de un objeto o concepto del
mundo real que se describe en una base de datos.
Una entidad se describe en la estructura de la base de datos empleando un
modelo de datos.
Por ejemplo, nombres de entidades pueden ser: Alumno, Empleado, Artículo, etc.
Cada entidad está constituida por uno o más atributos. Por ejemplo, la entidad
"Alumno" podría tener los atributos: nombre, apellido, año de nacimiento, etc.
Registro o Tupla
En informática, o concretamente en el contexto de una base de datos relacional,
un registro (también llamado fila o Tupla) representa un objeto único de datos
implícitamente estructurados en una tabla. En términos simples, una tabla de una
base de datos puede imaginarse formada de filas y columnas o campos. Cada fila
de una tabla representa un conjunto de datos relacionados, y todas las filas de la
misma tabla tienen la misma estructura.
Un registro es un conjunto de campos que contienen los datos que pertenecen a
una misma repetición de entidad. Se le asigna automáticamente un número
consecutivo (número de registro) que en ocasiones es usado como índice aunque
lo normal y práctico es asignarle a cada registro un campo clave para su
búsqueda.
La estructura implícita de un registro y el significado de los valores de sus campos
exige que dicho registro sea entendido como una sucesión de datos, uno en cada
columna de la tabla. La fila se interpreta entonces como una variable relacional
compuesta por un conjunto de tuplas, cada una de las cuales consta de dos ítems:
el nombre de la columna relevante y el valor que esta fila provee para dicha
columna.
Cada columna espera un valor de un tipo concreto.
Campo (informática)
En informática, un campo es un espacio de almacenamiento para un dato en
particular. En las bases de datos, un campo es la mínima unidad de información a
la que se puede acceder; un campo o un conjunto de ellos forman un registro,
donde pueden existir campos en blanco, siendo éste un error del sistema. En las
hojas de cálculo los campos son llamados celdas. La mayoría de los campos
tienen atributos asociados a ellos. Por ejemplo, algunos campos son numéricos
mientras otros almacenan texto, también varía el tamaño de estos.
Adicionalmente, cada campo tiene un nombre.
Tipos de Campo
Un campo puede ser:
Campo genérico
Aquel campo que posee un dato único para una repetición de entidad. Puede
servir para la búsqueda de una entidad en específico.
Alfanuméricos: Contiene cifras y letras. Presentan una longitud limitada (255
caracteres).
Numéricos: Existen de varios tipos principalmente como enteros y reales.
Booleanos: Admite dos valores, "Verdadero" y "Falso" (True-False).
Modelo entidad-relación
Un diagrama o modelo entidad-relación (a veces denominado por sus siglas, ER "Entity relationship", o, "DER" Diagrama de Entidad Relación) es una
herramienta para el modelado de datos de un sistema de información. Estos
modelos expresan entidades relevantes para un sistema de información así como
sus interrelaciones y propiedades.
Modelado Entidad-Relación
El Modelo Entidad-Relación.
1. Se elabora el diagrama (o diagramas) entidad-relación.
2. Se completa el modelo con listas de atributos y una descripción de otras
restricciones que no se pueden reflejar en el diagrama.
Dado lo rudimentario de esta técnica se necesita cierto entrenamiento y
experiencia para lograr buenos modelos de datos.
El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras
técnicas para lograr un modelo directamente implementable en una base de datos.
Brevemente:

Transformación de relaciones múltiples en binarias.

Normalización de una base de datos de relaciones (algunas relaciones
pueden transformarse en atributos y viceversa).

Conversión en tablas (en caso de utilizar una base de datos relacional).
LLAVE PRIMARIA O IDENTIFICADORA.
Cada instancia de una entidad debe ser unívocamente identificable, de manera tal
que cada registro de la entidad debe estar separado y ser unívocamente
identificable del resto de los registros de esa misma entidad; y quien permite esta
identificación es la llave primaria. La llave primaria, que generalmente se
identificada por medio de la letra @, puede ser un atributo o una combinación de
atributos.
En consecuencia en cada archivo solo podrá existir un único registro que posea un
valor determinado para su llave primaria. En otras palabras no puede existir en un
archivo un registro que cuente con el mismo valor de otro registro en el campo de
la llave primaria; la llave primaria no puede tener valores repetidos para distintos
registros.
La llave primaria debe permitirle a un Sistema de Gestión de Base de Datos
(SGBD), correctamente proyectado, generar un error si un usuario intenta incluir
un nuevo registro cuya llave primaria coincida con la de otro registro ya existente
en el archivo.
Clave primaria
En el diseño de bases de datos relacionales, se llama clave primaria a un campo
o a una combinación de campos que identifica de forma única a cada fila de una
tabla. Una clave primaria comprende de esta manera una columna o conjunto de
columnas. No pueden haber dos filas en una tabla que tengan la misma clave
primaria.
Una clave primaria debe identificar unívocamente a todas las posibles filas de una
tabla y no solo a las filas que se encuentran en un momento determinado.
Ejemplos de claves primarias son DNI (asociado a una persona) o ISBN (asociado
a un libro). Las guías telefónicas y diccionarios no pueden usar nombres o
palabras o números del sistema decimal de Dewey como claves candidatas,
porque no identifican unívocamente números de teléfono o palabras.
Una clave primaria es un caso especial de clave única. La mayor diferencia es
que para claves únicas, no se impone automáticamente la restricción implícita
NOT NULL, mientras que para claves primarias, sí. Así, los valores en columnas
de clave única pueden o no ser NULL. Otra diferencia es que las claves primarias
deben definirse por medio de otra sintaxis.
El modelo relacional, según se lo expresa mediante cálculo relacional y álgebra
relacional, no distingue entre clave primaria y otros tipos de claves. Las claves
primarias fueron agregadas al estándar SQL principalmente para conveniencia del
programador.
Tanto claves únicas como claves primarias pueden referenciarse con claves
foráneas.
Clave foránea
En el contexto de bases de datos relacionales, una clave foránea (o Foreign Key
FK) es una limitación referencial entre dos tablas. La clave foránea identifica una
columna o grupo de columnas en una tabla (tabla hija o referendo) que se refiere a
una columna o grupo de columnas en otra tabla (tabla maestra o referenciada).
Las columnas en la tabla referendo deben ser la clave primaria u otra clave
candidata en la tabla referenciada.
Los valores en una fila de las columnas referendo deben existir solo en una fila en
la tabla referenciada. Así, una fila en la tabla referendo no puede contener valores
que no existen en la tabla referenciada. De esta forma, las referencias pueden ser
creadas para vincular o relacionar información. Esto es una parte esencial de la
normalización de base de datos. Múltiples filas en la tabla referendo pueden hacer
referencia, vincularse o relacionarse a la misma fila en la tabla referenciada.
Mayormente esto se ve reflejado en una relación uno (tabla maestra o
referenciada) a muchos (tabla hija o referendo).
La tabla referendo y la tabla referenciada pueden ser la misma, esto es, la clave
foránea remite o hace referencia a la misma tabla. Esta clave externa es conocida
en SQL: 2003 como auto-referencia o clave foránea recursiva. Una tabla puede
tener múltiples claves foráneas y cada una puede tener diferentes tablas
referenciadas. Cada clave foránea es forzada independientemente por el sistema
de base de datos. Por tanto, las relaciones en cascada entre tablas pueden
realizarse usando claves foráneas. Configuraciones impropias de las claves
foráneas o primarias o no forzar esas relaciones son frecuentemente la fuente de
muchos problemas para la base de datos o para el moldeamiento de los mismos.
Formas Normales
Las formas normales son aplicadas a las tablas de una base de datos. Decir que
una base de datos está en la forma normal N es decir que todas sus tablas están
en la forma normal N.
Diagrama de inclusión de todas las formas normales.
En general, las primeras tres formas normales son suficientes para cubrir las
necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras
formas normales (o reglas) fue Edgar F. Codd.
Primera Forma Normal (1FN)
Una tabla está en Primera Forma Normal si:

Todos los atributos son atómicos. Un atributo es atómico si los elementos
del dominio son indivisibles, mínimos.

La tabla contiene una clave primaria única.

La clave primaria no contiene atributos nulos.

No debe de existir variación en el número de columnas.

Los Campos no clave deben identificarse por la clave (Dependencia
Funcional)

Debe Existir una independencia del orden tanto de las filas como de las
columnas, es decir, si los datos cambian de orden no deben cambiar sus
significados
Una tabla no puede tener múltiples valores en cada columna. Los datos son
atómicos. (Si a cada valor de X le pertenece un valor de Y y viceversa)
Esta forma normal elimina los valores repetidos dentro de una BD
Segunda Forma Normal (2FN)
Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los
atributos que no forman parte de ninguna clave dependen de forma completa de la
clave principal. Es decir que no existen dependencias parciales. (Todos los
atributos que no son clave principal deben depender únicamente de la clave
principal).
En otras palabras podríamos decir que la segunda forma normal está basada en el
concepto de dependencia completamente funcional. Una dependencia funcional
es completamente funcional si al eliminar los atributos A de X significa que
la dependencia no es mantenida, esto es que
. Una
dependencia funcional
es una dependencia parcial si hay algunos atributos
que pueden ser eliminados de X y la dependencia todavía se mantiene,
esto es
.
Por ejemplo {DNI, ID_PROYECTO}
HORAS_TRABAJO (con el DNI de un
empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana
trabaja un empleado en dicho proyecto) es completamente dependiente dado que
ni DNI
HORAS_TRABAJO ni ID_PROYECTO
HORAS_TRABAJO mantienen
la dependencia. Sin embargo {DNI, ID_PROYECTO}
NOMBRE_EMPLEADO es
parcialmente dependiente dado que DNI
dependencia.
NOMBRE_EMPLEADO mantiene la
Tercera Forma Normal (3FN)
La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia
funcional transitiva entre los atributos que no son clave.
Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un
esquema de relación R es una dependencia transitiva si hay un conjunto de
atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X>Z y Z->Y.
Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en
EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el
atributo clave SSN es transitiva vía DNUMBER porque las dependencias
SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es
un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la
dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado
que DNUMBER no es una clave de EMP_DEPT.
Formalmente, un esquema de relación R está en 3 Forma Normal ElmasriNavathe,2 si para toda dependencia funcional
, se cumple al menos una
de las siguientes condiciones:
1. X es superllave o clave.
2. A es atributo primo de R; esto es, si es miembro de alguna clave en R.
Además el esquema debe cumplir necesariamente, con las condiciones de
segunda forma normal.
Forma normal de Boyce-Codd (FNBC)
La tabla se encuentra en FNBC si cada determinante, atributo que determina
completamente a otro, es clave candidata. Deberá registrarse de forma anillada
ante la presencia de un intervalo seguido de una formalización perpetua, es decir
las variantes creadas, en una tabla no se llegaran a mostrar, si las ya planificadas,
dejan de existir.
Formalmente, un esquema de relación R está en FNBC, si y sólo si, para toda
dependencia funcional
válida en R, se cumple que
1. X es superllave o clave.
De esta forma, todo esquema R que cumple FNBC, está además en 3FN; sin
Cuarta Forma Normal (4FN)
Una tabla se encuentra en 4FN si, y sólo si, para cada una de sus dependencias
múltiples no funcionales X->->Y, siendo X una super-clave que, X es o una clave
candidata o un conjunto de claves primarias.
Quinta Forma Normal (5FN)
Una tabla se encuentra en 5FN si:

La tabla está en 4FN

No existen relaciones de dependencias no triviales que no siguen los
criterios de las claves. Una tabla que se encuentra en la 4FN se dice que
está en la 5FN si, y sólo si, cada relación de dependencia se encuentra
definida por las claves candidatas.
Entidades fuertes y débiles
Cuando una entidad participa en una relación puede adquirir un papel fuerte o
débil. Una entidad débil es aquella que no puede existir sin participar en la
relación, es decir, aquella que no puede ser unívocamente identificada solamente
por sus atributos. Una entidad fuerte (también conocida como entidad regular) es
aquella que sí puede ser identificada unívocamente. En los casos en que se
requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a
una entidad débil para que, esta última, se pueda identificar.
Las entidades débiles se representan- mediante un doble rectángulo, es decir, un
rectángulo con doble línea.
Cardinalidad de las relaciones
El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la
relación, respectivamente: "1:1", "1:N" y "N:M", aunque la notación depende del
lenguaje utilizado, la que más se usa actualmente es el unificado. Otra forma de
expresar la cardinalidad es situando un símbolo cerca de la línea que conecta una
entidad con una relación:

"0" si cada instancia de la entidad no está obligada a participar en la
relación.

"1" si toda instancia de la entidad está obligada a participar en la relación y,
además, solamente participa una vez.

"N" , "M", ó "*" si cada instancia de la entidad no está obligada a participar
en la relación y puede hacerlo cualquier número de veces.
Ejemplos de relaciones que expresan cardinalidad:

Cada esposo (entidad) está casado (relación) con una única esposa
(entidad) y viceversa. Es una relación 1:1.

Una factura (entidad) se emite (relación) a una persona (entidad) y sólo
una, pero una persona puede tener varias facturas emitidas a su nombre.
Todas las facturas se emiten a nombre de alguien. Es una relación 1:N.

Un cliente (entidad) puede comprar (relación) varios artículos (entidad) y un
artículo puede ser comprado por varios clientes distintos. Es una relación
N:M.
Atributos en relaciones
Las relaciones también pueden tener atributos asociados. Se representan igual
que los atributos de las entidades. Un ejemplo típico son las relaciones de tipo
"histórico" donde debe constar una fecha o una hora. Por ejemplo, supongamos
que es necesario hacer constar la fecha de emisión de una factura a un cliente, y
que es posible emitir duplicados de la factura (con distinta fecha). En tal caso, el
atributo "Fecha de emisión" de la factura debería colocarse en la relación "se
emite".
Diagrama entidad-relación
Anteriormente detallamos los conceptos relacionados al modelo ER, en esta
sección profundizaremos en como representarlos gráficamente. Cabe destacar
que para todo proceso de modelado, siempre hay que tener en claro los
conceptos, estos nos brindan conocimiento necesario y además fundamentan
nuestro modelo al momento de presentarlo a terceros.
Formalmente, los diagramas ER son un lenguaje gráfico para describir conceptos.
Informalmente, son simples dibujos o gráficos que describen información que trata
un sistema de información y el software que lo automatiza.
Entidad
Las entidades son el fundamento del modelo entidad relación. Podemos adoptar
como definición de entidad cualquier cosa o parte del mundo que es distinguible
del resto. Por ejemplo, en un sistema bancario, las personas y las cuentas
bancarias se podrían interpretar como entidades. Las entidades pueden
representar entes concretos, como una persona o un avión, o abstractas, como
por ejemplo un préstamo o una reserva. Se representan por medio de un
rectángulo.
Atributo
Se representan mediante un círculo o elipse etiquetado mediante un nombre en su
interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha
etiqueta.
Relaciones
Se representa mediante un rombo etiquetado en su interior con un verbo. Este
rombo se debe unir mediante líneas con las entidades (rectángulos) que relaciona.
Por motivos de legibilidad, los atributos no suelen representarse en un diagrama
entidad-relación, sino que se describen textualmente en otros documentos
adjuntos.
Diseño de una base de datos
Existen distintos modos de organizar la información y representar las relaciones entre los
datos en una base de datos. Los Sistemas administradores de bases de datos
convencionales usan uno de los tres modelos lógicos de bases de datos para hacer
seguimiento de las entidades, atributos y relaciones. Los tres modelos lógicos
principalmente de bases de datos son el jerárquico, de redes y el relacional. Cada modelo
lógico tiene ciertas ventajas de procesamiento y también ciertas ventajas de negocios.
Modelo de jerárquico de datos:
Una clase de modelo lógico de bases de datos que tiene una estructura arborescente. Un
registro subdivide en segmentos que se interconectan en relaciones padre e hijo y muchos
más. Los primeros sistemas administradores de bases de datos eran jerárquicos. Puede
representar dos tipos de relaciones entre los datos: relaciones de uno a uno y relaciones
de uno a muchos
Modelo de datos en red:
Es una variación del modelo de datos jerárquico. De hecho las bases de datos pueden
traducirse de jerárquicas a en redes y viceversa con el objeto de optimizar la velocidad y la
conveniencia del procesamiento. Mientras que las estructuras jerárquicas describen
relaciones de muchos a muchos.
Modelo relacional de datos:
Es el más reciente de estos modelos, supera algunas de las limitaciones de los otros dos
anteriores. El modelo relacional de datos representa todos los datos en la base de datos
como sencillas tablas de dos dimensiones llamadas relaciones . Las tablas son semejantes
a los archivos planos, pero la información en más de un archivo puede ser fácilmente
extraída y combinada.
Requerimientos de las Bases de Datos
El análisis de requerimientos para una base de datos incorpora las mismas tareas
que el análisis de requerimientos del software. Es necesario un contacto estrecho
con el cliente; es esencial la identificación de las funciones e interfaces; se
requiere la especificación del flujo, estructura y asociatividad de la información y
debe desarrollarse un documento formal de los requerimientos. Un tratamiento
completo del análisis de las bases de datos va mas allá del ámbito de este papel.
Modelo Físico
El paso de un modelo lógico a uno físico requiere un profundo entendimiento del
manejador de bases de datos que se desea emplear, incluyendo características como:





Conocimiento a fondo de los tipos de objetos (elementos) soportados
Detalles acerca del indexamiento, integridad referencial, restricciones, tipos de
datos, etc
Detalles y variaciones de las versiones
Parámetros de configuración
Data Definition Language (DDL)
Como se comentó en el modelado lógico el paso de convertir el modelo a tablas hace que
las entidades pasen a ser tablas (más las derivadas de las relaciones) y los atributos se
convierten en las columnas de dichas tablas.
Físicamente esta metáfora de una tabla se mapea al medio físico, con algunas
consideraciones como se menciona en las siguientes secciones.
Atributos
Tipos de Datos
Revisar los tipos de datos disponibles en el DBMS, en especial




Número de dígitos en números enteros
La precisión de los flotantes
Cadenas de caracteres de longitud fija (char(50)) y variable (varchar(50))
Blobs (Binary large objects) y Clobs (Character large objects)
Orden de las atributos (columnas)
Algo importante dependiendo del dbms que se utilice pero por lo general la secuencia es:



Columnas de longitud fija que no se actualizan frecuentemente.
Aquellas que nunca se actualizan que por lo general tendrán longitud variable.
Las que se actualizan frecuentemente.
Integridad Referencial



En la medida de lo posible indicar cuales columnas brindan o sirven de vínculo
entre 2 tablas.
El usuario (programador) puede hacerse cargo de esto pero es mejor que el dbms
se haga cargo.
No se recomienda en ambientes de desarrollo.
Índices
"Es una tabla que contiene una lista de elementos (llaves) y números de referencia donde
dichos elementos se encuentran (campos de referencia)".
Un índice es un atajo desde un campo llave hacia la localización real de los datos.
Es el punto clave de la optimización de velocidad de toda base de datos.
Si se busca alguna tupla en base a un atributo que no tiene un índice entonces se realiza un
escaneo de la tabla completa lo cual es demasiado costoso, por eso es recomendable usar
índices en:




Llaves primarias
Llaves foráneas
Indices de acceso
Ordenamiento
Lenguaje de consulta
Un lenguaje de consulta es un lenguaje informático usado para hacer consultas en
bases de datos y sistemas de información.
























Los lenguajes de consulta pueden ser clasificados de acuerdo a si son lenguajes
de consulta de bases de datos o lenguajes de consulta de recuperación
de información. Algunos ejemplos son:
.QL es un lenguaje de consulta propietario orientado a objetos para consultar
bases de datos relacionales;1
Common Query Language (CQL) un lenguaje formal para representar consultas
para sistemas de recuperación de información como índices web o catálogos
bibliográficos.
CODASYL;
D es un lenguaje de consulta para sistemas de administración de bases de datos
verdaderamente relacionales (truly relational database management systems TRDBMS);2
DMX es un lenguaje para modelos de minería de datos;
Datalog es un lenguaje de consulta para bases de datos deductivas;
ERROL es un lenguaje de consulta sobre el modelo entidad-relación (ERM),
especialmente diseñado para bases de datos relacionales;
Gellish English es un lenguaje que puede ser usado para consultas en bases de
datos Gellish English,3 para diálogos (pedidos y respuestas) como también para
modelado de información y modelado de conocimiento;
ISBL es un lenguaje de consulta para PRTV, uno de los más recientes sistemas de
administración de bases de datos;
LDAP es un protocolo de aplicación para consultar y modificar servicios de
directorios corriendo sobre TCP/IP.
MQL es un lenguaje de consulta de quimioinformática para búsqueda de
subestructuras permitiendo propiedades nominales y numéricas;
MDX es un lenguaje de consulta para bases de datos OLAP;
OQL es un lenguaje de consulta de objetos;
OCL (Object Constraint Language - lenguaje de restricciones de objetos). Pese a su
nombre, OCL es también un lenguaje de consulta de objetos y un estándar OMG.
OPath, pensado para el uso consultando almacenes WinFS;
Poliqarp Query Language es un lenguaje de consulta especial diseñado para
analizar texto con anotaciones. Usado en el motor de búqueda Poliqarp;4
QUEL es un lenguaje de acceso a bases de datos relacionales, muy similar a SQL;
SMARTS es el estándar de quimioinformática para búsqueda de subestructuras;5
SPARQL es un lenguaje de consulta para grafos RDF;
SQL es un lenguaje de consulta muy reconocido para bases de datos relacionales;
SuprTool es un lenguaje de consulta propietario para SuprTool,6 un programa de
acceso a bases de datos para obtener datos en Image/SQL (TurboIMAGE) y bases
de datos Oracle;
TMQL Topic Map Query Language es un lenguaje de consulta para Topic Maps;
XQuery es un lenguaje de consulta para fuentes de datos XML;
Macros
Una macro es un conjunto de una o más acciones (acción: componente básico de
una macro; instrucción independiente que se puede combinar con otras acciones
para automatizar tareas. A veces se denomina comando en otros lenguajes de
macros.) que cada una realiza una operación determinada, tal como abrir un
formulario o imprimir un informe. Las macros pueden ayudar a automatizar las
tareas comunes. Por ejemplo, puede ejecutar una macro que imprima un informe
cuando el usuario haga clic en un botón de comando.
Cuando se crea una macro, las acciones que se desea realizar se escriben en
esta parte de la ventana Macro (ventana Macro: ventana en la que se crean y
modifican las macros.).
En esta parte de la ventana se puede especificar los argumentos de una acción.
Una macro puede ser una macro compuesta de una secuencia de acciones, o
puede ser un grupo de macros (grupo de macros: colección de macros
relacionadas que se almacenan juntas bajo un único nombre de macro. A menudo,
se hace referencia a la colección simplemente como una macro.). También se
puede usar una expresión condicional (expresión condicional: expresión que se
evalúa y compara con un valor, por ejemplo, las instrucciones If...Then y Select
Case. Si se cumple la condición, se llevan a cabo una o más operaciones. Si no se
cumple, se omite la operación.) para determinar si se llevará a cabo una acción en
algunos casos cuando se ejecute la macro.
La siguiente macro está compuesta de una serie de acciones. Microsoft Access
lleva a cabo estas acciones cada vez que se ejecuta la macro. Para ejecutar esta
macro se hace referencia al nombre de la macro Revisar Productos.