Lecture
Identity Field Design Pattern
Stores the primary key from the database in the object to ensure consistency between the object and the string in the database.
Relational databases distinguish one record from another using a primary key. But objects in memory do not need such a key, since the object system follows the difference of objects itself. When reading from the database, there are no problems, but for writing, you need to bind the object system to the database.
There is nothing simpler and easier for this than the Identity Field. All you need is to store the primary key from the database in the object object.
Foreign Key Mapping Design Pattern
Represents foreign key relationships between tables as relationships between objects.
Objects can refer to each other directly, through object references. Even the simplest object-oriented system will contain a number of objects that are combined with each other in a variety of ways. To store these objects in the database, you must save these links. However, since different data is stored in objects at different times, it is not possible to save the values "as is". Even more complicated by the fact that objects can easily contain collections of links to other objects. Such a structure violates the normalization of relational databases.
The foreign key markup reduces the object reference to the foreign key in the database.
Design Pattern Association Table Mapping
Saves correspondence in the form of a table with foreign keys to the tables that are combined by this correspondence.
Objects can easily manage sets of several values when using collections as their own properties. Relational databases do not provide this capability and are limited to fields with a single value. When marking one-to-many correspondence, you can use the Foreign Key Mapping pattern, using a foreign key for a one-to-one correspondence. But the many-to-many relationship cannot provide this, because there is no single-valued entity to which the foreign key would refer.
The solution here is the classic resolution used in relational databases over the years: creating an additional table to store multiple links. Then using Association Table Mapping will allow you to mark multi-valued fields through a link table.
Dependent Mapping Design Pattern
One class provides mapping (distribution) for both the main class and the dependent class.
Some objects exist only in the context of other objects. Album songs can be loaded or saved at any time when the album is loaded or saved. If they are not used by other tables in the database, then the mapping process can be simplified by shifting the mapping of songs to the mapping object of the albums. This behavior is called Dependent Mapping.
Embedded Value Design Pattern
Writes an object to several fields in the table of another object.
Many small objects play an important role in an object-oriented system, but are not suitable for storage in a separate table. This, for example, objects-money, depending on the currency and date ranges. Despite the fact that usually a separate table is used to store a separate object, no one in a sober mind will begin to make a separate table for money.
The Embedded Value pattern distributes the values of the object fields to the fields of the owner object table.
The diagram shows the Employment object with links to objects in the range of dates and money. In the table that stores the object "place of work", the objects of dates and money are displayed on separate fields, but not stored in separate tables.
Design Pattern Serialized LOB
Storing the connection graph of objects in the database by serializing them into one large object (LOB).
The object model often contains complex graphs of interconnections of small objects. Most of the information in such structures is not contained in the objects themselves, but in the relations between them. For example, when working with the structure of an organization, the object model can quite well reflect all the interrelations between structures and it is easy to add methods that allow you to get data about departments and their interrelations.
But storing this structure in the database is not an easy task. The first solution that comes to mind is the table "organization" with the foreign key to the parent. But working with such a database structure requires using JOINs, which are both slow and cumbersome.
Objects do not need to be represented as related entries in a table. There is another form of representation, serialization, when the entire object graph is written into one LOB (large object).
Design Pattern Single Table Inheritance
Representation of all classes from the inheritance hierarchy as a single table in the database, containing columns for all fields of different classes.
Relational databases do not support inheritance, so by writing data about objects in the database, we have to figure out how to display inheritance in tables. Of course, we try to minimize the JOINs that will appear instantly if the inheritance is implemented by several tables in the database. The Single Table Inheritance pattern (inheritance with a single table) writes all the fields of all classes in a hierarchy into one table.
Design Pattern Class Table Inheritance
Represents a hierarchy of class inheritance in the form of a database structure, when one table corresponds to one class.
One of the most noticeable discrepancies between the object and the relational model is the lack of support for inheritance in the DDB. Sometimes a database structure is needed that exactly corresponds to the object model and allows the inheritance tree to grow. The Class Table Inheritance pattern (Inheritance with Class Tables) provides such capabilities using one table per class from the inheritance structure.
Concrete Table Inheritance Design Pattern
Represents a class inheritance hierarchy in the form of a database structure, when one table corresponds entirely to one class.
The problem of object-relational interaction is the lack of support for inheritance in DDB. If we consider the tables from an object point of view, it makes sense to write each object into a separate record in the database. This approach implements the Concrete Table Inheritance pattern, in which each specific class in the inheritance hierarchy has its own table.
Inherritance Mappers Design Pattern
The structure of the organization of data distributors that work with the inheritance tree
When working with the distribution of object data from the inheritance tree in the database, it is necessary to reduce the amount of code used to write and read data from the database. It is also necessary to provide both abstract and concrete data distribution methods that would allow saving and reading of both parent and child classes.
Despite the fact that the nuances of this behavior may vary depending on the scheme of working with a tree of division (Single Table Inheritance, Class Table Inheritance or Concrete Table Inheritance), the overall structure is the same for all of them.
Comments
To leave a comment
Web site or software design
Terms: Web site or software design