database - software - ¿Qué es una "entidad de base de datos" y qué tipos de elementos DBMS se consideran entidades?
database diagram tool (9)
¿Son cosas como tablas? ¿O también incluiría cosas como restricciones, procedimientos almacenados, paquetes, etc.?
He buscado en Internet, pero encontrar respuestas elementales a preguntas elementales a veces es un poco difícil.
¡Esa es una pregunta bastante general!
Básicamente, todos los tipos que ofrece el sistema de base de datos, como NUMERIC, VARCHAR, etc., o que ofrece el lenguaje de programación de elección (int, string, etc.) se consideran tipos de datos (base) "atómicos".
Todo lo que usted, basado en los requisitos de su programa o negocio, se basa en eso, los objetos comerciales, etc., son entidades.
Las tablas, las restricciones, etc., son objetos internos de la base de datos necesarios para almacenar y recuperar datos, pero estos no se consideran en general "entidades". Los datos almacenados en sus tablas, cuando se recuperan y se convierten en un objeto, entonces son una entidad.
Bagazo
Depende de cómo lo pienses y de cómo modelas tu dominio de problema. la mayoría de las veces, cuando escucha acerca de las entidades, son tablas de base de datos (una o varias) asignadas a clases de objetos. Entonces, en realidad no es una entidad hasta que se ha consultado y se ha convertido en una instancia de clase.
pero, de nuevo, depende de su metodología de modelado, y hay múltiples :-)
En el mundo de la relación de entidades, una entidad es algo que puede existir de manera independiente y, por lo tanto, a menudo existe una relación de uno a uno entre las entidades y las tablas de la base de datos. Sin embargo, este mapeo es una decisión de implementación: por ejemplo, un diagrama de ER puede contener tres entidades: Triángulo, Cuadrado y Círculo y estas podrían potencialmente modelarse como una sola tabla: Forma.
También tenga en cuenta que algunas tablas de base de datos pueden representar relaciones entre entidades.
Este hilo está demostrando una razón por la que es difícil encontrar "respuestas elementales a preguntas elementales". Ciertos paradigmas de programación han usado ciertas palabras para significar cosas diferentes (intente preguntar a un grupo de programadores OO cuál es la diferencia entre una Clase y un Objeto en algún momento).
Aquí está mi opinión sobre ello.
La primera vez que me topé con Entity fue un término modelo en SSADM (pregúntale a tu papá) En ese contexto, se utiliza una Entidad para modelar un grupo lógico de datos durante la fase de recopilación / análisis de requisitos. Las relaciones entre entidades se modelaron utilizando los diagramas de relaciones entre entidades, y el perfil de un Enity se modeló utilizando Entity Life Histories. Los diagramas de ELH fueron muy útiles en los sistemas COBOL pero absolutamente horribles en las bases de datos relacionales. Por otro lado, las ERD siguen siendo útiles hasta el día de hoy.
Durante las fases de diseño e implementación, las Entidades se resuelven en tablas de base de datos, objetos o registros en un archivo de entrada COBOL. En el curso de ese proceso, una entidad lógica puede dividirse en varias tablas, o varias entidades pueden convertirse en una sola tabla, o puede haber una asignación de uno a uno. A veces, una entidad se resuelve por completo o permanece como una vista o un procedimiento almacenado.
Esto parece útil: http://en.wikipedia.org/wiki/Entity-relationship_model
En una base de datos una entidad es una tabla. La tabla representa cualquier concepto del mundo real que intenta modelar (persona, transacción, evento).
Los contraints pueden representar relaciones entre entidades. Estas serían las claves foráneas. También imponen reglas como el primer nombre no puede estar en blanco (nulo). Una transacción debe tener 1 o más artículos. Un evento debe tener una fecha y hora.
Los procedimientos / paquetes / activadores almacenados pueden manejar relaciones más complejas y / o pueden manejar reglas de negocios, solo depende de lo que esté haciendo.
Las entidades son "cosas de importancia" para los usuarios / negocio / empresa / dominio de problemas.
Mi respuesta es obviamente un poco tarde, pero aquí está como se define en un libro de texto de certificación de base de datos:
Entidad: un elemento identificable de forma exclusiva sobre qué datos se almacenan en una base de datos.
y para aclarar la confusión de entidades y tablas,
La entidad no es una mesa. Las tablas se pueden llamar "tablas" o "relaciones", las palabras son sinónimos.
Necesitaríamos saber algo de contexto. Una cosa que las personas a veces hacen cuando analizan datos en preparación para diseñar una base de datos es crear un Diagrama de Realidad de Entidades, en el que está considerando qué elementos de datos está administrando y sus relaciones.
Me pregunto si ese es el contexto que quieres decir.
Si es así, tal vez una lectura de este http://en.wikipedia.org/wiki/Entity-relationship_model te ayude a comenzar.
Actualizar:
Ver este artículo en mi blog en el que trato de cubrir el tema con más detalle:
Una entidad es un término del entity-relationship model .
Un relational model (el esquema de su base de datos) es una de las formas de implementar el modelo ER.
Las tablas relacionales representan relaciones entre tipos simples como enteros y cadenas, que, a su vez, pueden representar todo: entidades, atributos, relaciones.
No puede saber qué es solo de la estructura relacional, necesita ver el modelo ER.
Para persons mesa,
id name surname
1 John Smith
id , name y surname son entidades en el mundo real y pueden o no representar entidades en el modelo ER subyacente.
El hecho de que exista un registro en la tabla significa que estas entidades están en la siguiente relación: "la person 1 tiene el nombre de John y tiene el apellido Smith ".
En el ejemplo anterior, la entidad se define por id (desde el punto de vista del modelo).
Si una persona cambia su nombre de John a Jack , la persona sigue siendo la misma (nuevamente, desde el punto de vista del modelo), pero se relaciona con otro name .
En el ejemplo anterior, el name y el surname se pueden tratar como un attribute (en lugar de una entity ), pero nuevamente, debe ver el modelo ER que implementa este esquema para indicar cuál es.
En algunas asignaciones de modelo ER-a-relacional, una entidad debe definirse en una tabla con una FOREIGN KEY para que se considere una entity (que debe restringir su dominio).
Sin embargo, esta restricción puede existir pero no estar representada en una base de datos (debido a limitaciones tecnológicas u otra cosa).
Al igual que, no podemos mantener una lista de todos los nombres posibles, pero el nombre de @#$^# probablemente no sea un nombre, por lo tanto, no pertenece al dominio de nombres.
Por lo tanto, un attribute es una entity que puede participar en una relación pero no puede estar contenida en una tabla de definición de dominio.
Por ejemplo, los prices la mesa:
good_id price
define las relaciones entre el conjunto de bienes (que se define por los goods la mesa) y el conjunto de números reales (que no pueden estar contenidos en una tabla, ya que ni siquiera es contable).
Aún así, cada precio (como $2.00 ) también es una entidad del mundo real.