What is the difference between object and entity in the database?
Please explain with an example.
An entity is an abstract concept that's typically represented by a table in a database schema. The term object usually refers to in-memory data structures. An object that represents an entity may be called an entity object (often mapped to a row in a database table), that is it's an instance of an entity class (often mapped to a table).
A database object is represented as database, schema, table, column, primary key, and foreign key While a database Entity is a concept or object of importance about which data must be captured.
Related
Let's assume we have 2 ERD entities connected with 1 relationship. Visual Paradigm allows to mark such a relationship as "Subtype" and "Identifying" at the same time. And I just fail to imagine any case where such a combination could make sense.
Is that actually legal? If yes I would appreciate some example and a procedure of translating it to the relational model (what are the changes in comparison to only-"Subtype" or only-"Identifying" case?).
What Visual Paradigm calls an ERD is in fact a table diagram. Diagrams that don't use shapes for relationships don't support attributes and relationships on relationships, nor ternary and higher order relationships. If a diagramming notation doesn't support all the concepts of the Entity-Relationship model, we can't call its diagrams Entity-Relationship diagrams.
From an ER point of view, all subtype relationships are identifying relationships, since the parent entity set's identity is a component of the child entity set's identity. However, all identifying relationships aren't subtype relationships. The difference between a subtype and a weak entity set is that the latter uses an additional weak key component to distinguish multiple children of a parent. Subtypes depend only on the supertype for identity and so each instance of the supertype can have only instance per subtype.
For example, an entity set Person (identified by person_id) may have a subtype Employee (which is also identified by person_id). Compare this with an Invoice (identified by invoice_id) and LineItem (identified by invoice_id and line_number).
The ERD (conceptual model) translates into the following tables (physical model):
I have got this question:
What is the equivalent of table in ERD, UML and in relation data model?
In Chen's ER model (and Chen-notation ERDs), data is represented as attributes of and relationships between entities. This is an interpretation of relations in the relational model, which understands data as associations between domains of values/entities. Relations (i.e. attributes and relationships) can be represented as tables, though tables and relations don't map 1-to-1 - certain rules and semantics must be applied to tables (such as eliminating merged cells, ensuring that every cell contains exactly one value, column values are from a single domain, no duplicate rows, and order of rows/columns aren't significant) to understand them as relations.
In non-Chen ERDs (the kind in products like Visual Paradigm and MySQL Workbench), tables are directly represented but called entities, and foreign keys constraints are called relationships. This is reminiscent of the pre-relational network model. UML class diagrams fall in this category when used for data modeling.
Do entity types/kinds have any special property or restriction compared to a Key? It seems to me that the entity type is just a key except it has no parent and the API clients use this concept to avoid collisions but technically there is no difference at the datastore level. It's all a big key. Am I right?
TL;DR: Yes, Entity Kind is different from the Key in that it is used for indexing purposes. Think of it as roughly analogous to a table name.
By entity type, I'm assuming you are referring to Entity Kind.
The Key of an entity is globally unique to your project, it is composed from the Entity Kind, its Id or Name, and optionally an ancestor path (which is more Kind and Id/Name pairs).
In the simplistic cases, you can think of a 'Kind' as a table name. Cloud Datastore automatically indexes every Entity by its Kind, which allows you to do 'global' queries for Entities of that Kind - regardless of whether they are a root Entity of the descendant of another entity.
Let's say I have a table called Data, and another table called ExtraData. ExtraData has a foreign key reference to Data's primary key. ExtraData is not guaranteed to have a row for every row in Data, but it can at most have one row associated to a row in Data. Is there a proper term for the type of table ExtraData is?
Bonus points on the answer if someone can point me to a resource that describes proper terminology in data modeling like this.
Thank you.
Data is called Base Table and ExtraData is called Derived Table.
Search Wikipedia page of Weak Entity for this term.
When sub-type relationships are rendered in a database, the super-type
becomes what is referred to as a base table. The sub-types are
considered derived tables, which correspond to weak entities.
What is the usage of keys in the appengine datastore: I am new to Appengine, any info on it would be great.
Comparison
To keep things simple, let's assume MySQL stores all the rows of a table in a single file. That way, it can find all the rows by scanning that file.
App Engine's datastore (BigTable) does not have a concept of tables. Each entity (~row in MySQL) is stored separately. [It can also have a individual structure (~columns).] Because entities are not connected in any way, there is no "default" method to go through all of them. Each entity needs an ID and must be indexed.
Key Structure
A key consists of:
App ID (the closest thing in MySQL is a database).
Kind (the closest thing in MySQL is a table).
ID or name (the closest thing in MySQL is a primary key).
(Optionally) Parent key (all the above of another entity). (Details omitted for the sake of simplicity.)
Please note that what is meant by the closest thing is conceptual similarity. Technically, these things are not related. In MySQL, databases and tables represent actual storage structures. In BigTable they are just IDs, and the storage is actually flat, i.e. every entity is essentially a file.
In other words, identity-wise, a key is to an entity as the database + table + primary key are to a row in a MySQL table.
Key's Responsibilities
An entity's key:
States what application the entity belongs to.
What kind (class, table) it is of.
By the means of the above and either a numeric key ID or a textual key name, identifies the entity uniquely.
(Optionally) What the parent entity of the entity is. (Details omitted for the sake of simplicity.)
Usage
So that you can retrieve all entities of a kind, App Engine automatically builds indexes. That means App Engine maintains a list of all your entities. More specifically, it maintains a list of your entities' keys.
Complex indexes may be defined to run queries on multiple properties (~columns).
In contrast to MySQL, every BigTable query requires an index. Whenever a query is run, the corresponding index is scanned to find the entities that meet the query's conditions, and then the individual entities are retrieved by key.
A common high-level use is to identify an entity in a URL, as every key can be represented as a URL-safe string. When an entity's key is passed in the URL, the entity can be retrieved unambiguously, as the key identifies it uniquely.
Moreover, retrieving an entity by its key is strongly consistent, as opposed to queries on indexes, which means that when entity is retrieved by its key, it's guaranteed to be the latest version.
Tips
Every entity stored in BigTable has a key. Such a key may be programmatically created in your application and given an arbitrary key name. If it's not, an numeric ID will be allocated transparently, as the entity is being stored.
Once an entity is stored, its key may not be changed.
The optional parent component might be used to define a hierarchy of entities, but what it's really important for is transactions and strong consistency.
Entities that share a parent are said to belong to the same entity group.
Queries within a group are strongly consistent.
Just to reiterate, retrieving an entity by its key or querying an index by a parent key are strongly consistent. Retrieving entities in other ways (e.g. by a query on a property) is eventually consistent.
Glossary
Entity - a single key-value document.
Eventual consistency - retrieving an entity (often a number of them) without the guarantee that the replication has completed, which may result in some entities being an old version and some being missing, as they have not yet been brought from the server they were stored on.
Key - an entity's ID.
Kind - arbitrary textual name of a class of entities, such as User or Article.
Key ID - a numeric identifier of a key. Usually automatically allocated.
Key name - a textual identifier of a key.
Strong consistency - retrieving an entity in such a way that its latest version is retrieved.
(I intentionally used MySQL in the examples, as I'm much more familiar with it than with any other relational database.)
Please read https://developers.google.com/appengine/docs/java/datastore/#Java_Entities ... you may want to delete your question and ask again after you have studied this documentation section.
(This is meant to help you, not complain.)