Object link ing-part.1

Source: http://www.cnblogs.com/JimmyZhang/archive/2007/10/03/913337.html

PDF browse: http://www.tracefact.net/document/Object-Relational-Mapping-Part1.pdf

Object link ing-part.1 Introduction

In most cases, everyone is using the object-oriented idea for program development and design. At the same time, the database that deals with us the most is relational database. How to make the objects in these two different fields collaborate naturally becomes one of the most frequently discussed topics.

As the first article in this series, I mainly introduced some preliminary knowledge and basic concepts of object link ing. It mainly includes one-to-one relationship, object-oriented basis, and relational basis, and briefly discusses the differences between objects and relations.

The full name of object link ing is object relational ing, abbreviated as Orm. For ease, the object link ing mentioned below uses Orm.

One-to-one relationship

Before describing object link ORM ing Orm, we need to first understand what a one-to-one relationship is and how to implement a one-to-one relationship. A one-to-one relationship is also called a superclass/subclass relationship.

In actual development, the most familiar database relationship may be one-to-many. For example, there are many essays under a category, and for example, there are many comments under an essay. Without knowing it, one-to-one implementation is required without thinking about it.

Let's take a look at this example to simplify the demo:

If we are designing a forum user table, we generally need the following fields: userid, user ID; Name, user name; password, password; email, and email. We also need to set the Administrator and moderator, so we will continue to add the field: adminpwd, background password; level, user level: 0, common member; 1, moderator; 2, administrator.

The table creation script is as follows:

Create Table [user]
(
Userid int identity (1, 1 ),
Name varchar (30) not null,
Password varchar (50) not null,
Email varchar (50) not null,
Adminpwd varchar (50) null,
Level tinyint not null default 0 constraint ck_userlevel check (level between 0 and 2) -- 0, common member; 1, moderator; 2, Administrator

Constraint pk_user primary key (userid) -- create a primary key
)

Soon we will find that the ratio of users to administrators is usually. At this time, for 99.9% of users, the adminpwd field is null and the level field is 0. To avoid unnecessary waste of space, we abstract the Administrator and create a new admin table.

At this time, the problem arises. Many people use this method:

Create Table [user]
(
Userid int identity (1, 1 ),
Name varchar (30) not null,
Password varchar (50) not null,
Email varchar (50) not null,

Constraint pk_user primary key (userid) -- create a primary key
)

Create Table Admin
(
Adminid int identity (1, 1 ),
Adminpwd varchar (50) null,
Level tinyint not null default 1 constraint ck_userlevel check (level between 1 and 2 ),
Fkuserid int not null

Constraint pk_admin primary key (adminid) -- create a primary key
)

In the admin table, many users use fkuserid to correspond to the userid in the User table for administrator-user correspondence. In fact, this is a typical one-to-many relationship. Because, you can have two different administrators with the same fkuserid field value, that is, the same user in the corresponding user table. At this time, data consistency has been damaged. In addition, a meaningless field adminid is generated.

So what is a reasonable solution? The specific implementation script is as follows:

Create Table [user]
(
Userid int identity (), -- primary key of the master table
Name varchar (30) not null,
Password varchar (50) not null,
Email varchar (50) not null,

Constraint pk_user primary key (userid)
)

Create Table Admin
(
Userid int, -- cannot be auto-incrementing
Adminpwd varchar (50) null,
Level tinyint not null default 1 constraint ck_userlevel check (level between 1 and 2), -- 1, moderator; 2, Administrator

Constraint pk_admin primary key (userid) -- create the primary key of the slave table
)

Alter table admin -- create a foreign key from the table
Add constraint fk_admin_user foreign key (userid) References user (userid)
On Delete no action on update no action

Let's see what is the difference between the present and the previous one?

1. Why is the adminid field renamed as userid? My principle is: If fields in a table have the same meaning as those in another table, their names are the same, and the fields contained in the foreign key depend on the situation.
2. The USERID field is no longer an auto-incrementing type. It is easy to understand that it corresponds to the userid in the User table to represent the same person. The USERID in the User table is already auto-incrementing. Of course, it cannot be auto-incrementing. Otherwise, how can this problem be solved?
3. The reason for canceling the fkuserid field is simple, because userid is not only a primary key, but also a foreign key, used to correspond to the USERID field of the User table.

In this instance:

• Userid is the primary key, which ensures that only one userid can be unique in the admin table.
• Userid is a foreign key, which ensures that it corresponds to a record that already exists in the User table, that is, a user.

We will summarize the features of one-to-one relationship implementation:

1. The primary key of the primary table is auto-incrementing or any other type that uniquely identifies the record.
2. The name and meaning of the primary key (including fields) of the slave table are the same as those of the primary key (including fields) of the master table.
3. The foreign key (included field) of the slave table is the same as the primary key (included field) of the slave table.
4. The foreign key (included field) of the slave table corresponds to the primary key (included field) of the master table ).

Basic object-oriented types

In my opinion, type is the most important concept in object-oriented thinking. Many other concepts are derived from it. Many of my friends think that defining a class is to define a type, and this understanding is biased.

The type is determined by the class interface. When we mention the type of an object, we actually talk about What interfaces It has, rather than how its interfaces are implemented. In turn, the type is the interface defined in detail and supported by the object.

Note:If an object implements all the interfaces of the type definition, we can say that this object implements this type, which is a certain type of object. If an object implements many types of interfaces, it is also of many types.

The gof four-person group mentioned in its Book Design Patterns page 13th that a type is a name used to denote a special interface. we speak of an object as having the type "window" if it accepts all requests for the operation defined in the interface "window ".

The type indicates the name of a specific interface. If an object meets all the requirements defined in the "window" interface, we will say that this object has the "window" type.

Contact

The type does not exist in isolation. A type can be associated with other types. If there is a link between two types, an object of a certain type can be converted to another type.

Note:We are talking about object-oriented polymorphism all day, wondering why a class instance can be converted to its interface type, and there is nothing to do with the interface, it only defines a bunch of methods and attribute signatures.
Do you understand now?This is because of the relationship between types. The interface defines the type, and the class is associated with it.

Class

Class defines the specific implementation of objects (in turn, the instance of the class. It defines the type of an object. To put it bluntly, classes implement interfaces (abstract classes are special cases ).

Inheritance

Inheritance can be type inheritance or class inheritance.

When it is type inheritance: if an object is type B and Type B inherits from type A, we can say that this object is also type.

When it comes to class inheritance: we say that a class inherits the implementation of another class. At the same time, the inherited class does not lose its coverage of its base class.

Status

The State concept is relatively easy to understand. It usually refers to a set of values owned by an object.

Action

Object behavior refers:

• The set of operations provided by an object, that is, its interface.
• The response of an object to other objects that call it is generally the return value of the method.
• The impact of operations on the object itself.

All interaction and understanding of an object is done through its behavior.

Encapsulation

Encapsulation makes the object an independent individual independent from other objects. External implementations are invisible. For example, when you interact with an encapsulated object, you can only use the interface provided by it, but you cannot know the specific implementation within the interface.

Note:This chapter is only a description of the following sections. The content is simple. If you are interested in Object-Oriented Programming, you can refer to relevant books.

Link Basics

This chapter describes the relationship. Although some concepts are somewhat similar to the previous object-oriented concepts, do not try to use the object-oriented idea to understand the concepts in the relationship.

Link

A link defines a set of attributes, which are combined to form a meaningful thing. Taking the one-to-one relationship we have discussed as an example, one of the relationships is: User {Name, email, gender, birthday }.

Attribute

An attribute is an integral part of a link. It provides a basis for distinguishing different links. For example, why is the relationship between user {name, email, gender, birthday} and car {name, color, speed, price} different? Not because "user" means "user", but "car" means "car", but because their attributes are different.

The property also defines the range of the property value. For example, the gender (gender) attribute of the user relationship can only be {male, female}, and no other value can be set.

Value Range

Simply put, a value field is a data type, or a value range. For example, in the Gender attribute mentioned above, its value is {male, female }.

Tuples

Just like a car, a relationship is an abstraction at a very high level and does not represent a specific thing. Only when all attributes of a link have specific values in its value range can it represent an actual thing.

When we assign a specific value in the value range to all the attributes of a link, a tuples are formed.

Let's take the preceding user relationship as an example. One of its tuples is:

<User name = "Zhang Ziyang" Gender = "male" email = "jimmy_dev@163.com" Birthday = "1982-12-8">

For multiple tuples, if all their attribute values are the same, we will say they are the same tuples.

Link Value

A group of tuples forms a relational value. Let's take user as an example. One of its relational values is:

{
<User name = "Zhang Ziyang" Gender = "male" email = "jimmy_dev@163.com" Birthday = "1982-12-8">
<User name = "Wang Wu" Gender = "male" email = "Wang5@cnblogs.com" Birthday = "1983-7-17">
<User name = "" Gender = "female" email = "Li4@cnblogs.com" Birthday = "1984-5-20">
}

For link values:

• Duplicate tuples do not exist.
• The order of tuples is irrelevant.

Relationship and table

In a relational database, a link is usually in the form of a table. For example, the above user relationship is usually expressed in a database as a user table similar to the following.

User table

Name	Gender	Email	Birthday
Zhang Ziyang	Male	Jimmy_dev@163.com	1982-12-8
Li Si	Female	Li4@cnblogs.com	1983-7-17
Wang Wu	Male	Wang5@cnblogs.com	1984-5-20

Terms for relational systems and database systems

Database System	Relational system
Table)	Relationship)
Row)	Tuple)
Column)	Attribute)
Data Type)	Domain)
Column Value)	Attribute Value)

Base Link

Now, let's take a look at the one-to-one relationship described in chapter 1 of this Article. In the previous example, the user relationship is a base relationship relative to the admin relationship.

Inheritance relationship

The subrelation is relative to the base relation, and the admin relation is an inheritance relation relative to the user.

Note:This chapter is only a description of the following chapters. The content is simple. If you are interested in relational systems, you can refer to discrete mathematics and introduction to relational database systems.

Object vs relationship

If we want to model the concept of "car", it has four attributes: name, head, body, and rear ).

Object-Oriented Approach

First, we define a car class:

Public class car {
Public string name;
Public String head;
Public String body;
Public String rear;

Public Car (name, head, body, rear ){
This. Name = Name;
This. Head = head;
This. Body = body;
This. Rear = rear;
}
}

When we need a BMW, a Mercedes-Benz (MB), and an Audi (Audi:

Car BMW = new car ("BMW", "BMW front", "BMW body", "BMW rear ");
Car MB = new car ("Mercedes", "Mercedes ")
Car AUDI = new car ("Audi", "Audi head", "Audi body", "Audi tail ")

Note:The above example is not suitable. You can think of carhead and carbody as entity classes with their own attributes.

Relational Database practices

Create four tables: carname, carhead, carbody, and carrear. Divide the three vehicles into four parts and place each part in the appropriate table, then assemble.

Problem proposal

If this is the case, the problem seems to be easily solved: Let the class attributes correspond to the fields in the table in the database.

Now, let's look back at the content in the previous section on Object-Oriented basics. objects are not only attributes, but also complex features such as behavior, encapsulation, inheritance, and contact. They cannot find a good match in the database. How can this problem be solved?

This article will introduce more content in subsequent articles.

Summary

In this article, we first understand what a one-to-one relationship is and how to implement a one-to-one relationship.

Then we reviewed and reviewed the basic concepts and theories of object-oriented and relational systems.

Finally, based on the previous knowledge, we propose the differences between object-oriented and relational systems in software development.

I hope this article will help you.