¿Son las cosas como las tablas? ¿O también incluiría cosas como restricciones, procedimientos almacenados, paquetes, etc.?¿Qué es una "entidad de base de datos" y qué tipos de elementos DBMS se consideran entidades?
He buscado en Internet, pero encontrar respuestas elementales a preguntas elementales a veces es un poco difícil.
En el mundo de relación de entidades una entidad es algo que puede existir independientemente y por lo tanto, a menudo existe una relación de uno a uno entre entidades y tablas de base de datos. Sin embargo, este mapeo es una decisión de implementación: por ejemplo, un diagrama ER puede contener tres entidades: Triángulo, Cuadrado y Círculo, y estos podrían ser modelados como una sola tabla: Forma.
También tenga en cuenta que algunas tablas de bases de datos pueden representar relaciones entre entidades.
depende de cómo piense y cómo modele el dominio de su problema. la mayoría de las veces cuando escuchas sobre entidades, son tablas de bases de datos (una o muchas) mapeadas en clases de objetos. Por lo tanto, no es realmente una entidad hasta que se haya consultado y se haya convertido en una instancia de clase.
pero de nuevo, depende de su metodología de modelado, y hay múltiples :-)
Esa es una pregunta general!
Básicamente, todos los tipos que ofrece el sistema de base de datos, como NUMERIC, VARCHAR etc., o que el lenguaje de programación de elección (int, cadena, etc.) se considerarían tipos de datos "atómicos" (base).
Todo lo que usted, basándose en los requisitos de su programa o negocio, a partir de eso, objetos de negocio, etc., son entidades.
Tablas, restricciones y demás son objetos internos de la base de datos necesarios para almacenar y recuperar datos, pero esos son generales no se consideran "entidades". Los datos almacenados en sus tablas, cuando se recuperan y se convierten en un objeto, que es una entidad.
Marc
Actualización:
Lee 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.
A relational model (su esquema de 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 se puede decir qué es solo de la estructura relacional, necesita ver el modelo ER.
Para la mesa persons,
id name surname
1 John Smith
id, name y surname son entidades en el mundo real y puede o no representar a las entidades en el modelo ER subyacente.
existe El hecho de un registro en la tabla significa que estas entidades están en la siguiente relación: "person 1 tiene nombre y Johntiene 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 el mismo (una vez más, desde el punto de vista del modelo), pero obtiene relacionado con otro name.
En el ejemplo anterior name y surname pueden ser tratados como attribute (a diferencia de entity), pero de nuevo, tiene que ver el modelo ER, que implementa este esquema de decir lo que es.
En algunas asignaciones de modelo ER-a-relacional, una entidad debe definirse en una tabla referenciable con FOREIGN KEY para ser considerada entity (que debería 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).
Me gusta, no podemos mantener una lista de todos los nombres posibles, pero el nombre de @#$^# es probablemente un nombre desconocido, por lo tanto, no pertenece al dominio de nombres.
Por lo tanto, un attribute es un entity que puede participar en una relación, pero no pueden ser contenidos en una tabla de dominio de definición.
Por ejemplo, la tabla prices:
good_id price
define las relaciones entre el conjunto de bienes (que se define por la mesa goods) y el conjunto de números reales (que no puede estar contenida en una tabla, ya que es ni siquiera contable).
Todavía cada precio (como $2.00) es una entidad del mundo real igual de bien.
no son ID, nombre y apellido ATRIBUTOS en lugar de ENTIDADES? –
Según entiendo, esta fila que representa a un "Smith, John" como TODO sería una entidad –
'@ marc_s': ¡paciencia! – Quassnoi
Necesitaríamos saber algo de contexto. Una cosa que las personas a veces hacen al analizar los datos en preparto para diseñar una base de datos es crear un Diagrama de Realidad de la Entidad, donde se consideran los elementos de datos que se están administrando y sus relaciones.
Me pregunto si ese es el contexto al que te refieres?
Si es así, ¿quizás una lectura de este article le pondría en marcha?
Este hilo está demostrando una razón por la cual es difícil encontrar "respuestas elementales a preguntas elementales". Ciertas palabras han sido utilizadas por diferentes paradigmas de programación para significar cosas diferentes (intente preguntarle 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 esto.
Encontré Entity por primera vez como un término de modelado en SSADM (pregúntele a su papá). En ese contexto, una Entidad se utiliza para modelar un grupo lógico de datos durante la fase de recopilación/análisis de requisitos. Las relaciones entre las entidades se modelaron utilizando los diagramas de relación de entidades, y el perfil de una Enity se modeló utilizando Entity Life Histories. Los diagramas ELH fueron muy útiles en los sistemas COBOL pero absolutamente horribles en las bases de datos relacionales. Los ERD, por otro lado, continúan siendo útiles hasta el día de hoy.
Durante las fases de diseño e implementación, las entidades se resuelven en tablas de bases de datos, objetos o registros en un archivo de entrada COBOL. En el transcurso de ese proceso, una entidad lógica puede dividirse en varias tablas, o varias entidades se pueden dividir en una única tabla, o puede haber una correspondencia 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 de una entidad es una tabla. La tabla representa cualquier concepto del mundo real que intente modelar (persona, transacción, evento).
Contraints puede representar relaciones entre entidades. Estas serían claves extranjeras. También imponen reglas como first_name no pueden estar en blanco (null). Una transacción debe tener 1 o más elementos. Un evento debe tener una fecha y hora.
Procedimientos almacenados/Paquetes/Disparadores pueden manejar relaciones más complejas y/o pueden manejar reglas comerciales, solo depende de lo que está haciendo.
explicación genial y simple! - "En una base de datos, una entidad es una tabla. La tabla representa cualquier concepto del mundo real que intente modelar (persona, transacción, evento)". –
Las entidades son "cosas de importancia" para los usuarios/negocios/empresas/problema de dominio.
Mi respuesta es, obviamente, un poco tarde, pero aquí es como se define en un libro de texto de certificación de base de datos:
Entidad: Un elemento único de identificación acerca de qué datos se almacenan en una base de datos.
y para aclarar la confusión entidad y mesa,
Entidad no es una tabla. Las tablas se pueden llamar "tablas" o "relaciones", las palabras son sinónimos.
Primero aclara tu respuesta – user1972007
Estoy de acuerdo con usted. Una "Entidad" suele ser la representación de un objeto del mundo real. Una tabla PERSONA es la entidad que representa a una persona del mundo real. Cosas como nombre, apellido, etc. son Atributos de la entidad. –