Data Modeling Using ORM based on facts (object role modeling) (Reading Notes)

ArticleDirectory

• 1. Some basic facts
• 2. Types of facts (declarative statements)
• 3. Constraints
• 4. Charts

Data Modeling is an application Program An important part of the design, especially for distributed applications. However, the method for creating a model is incomplete in many aspects. Dr. Terry Halpin of Microsoft proposed ORM (object role modeling) to solve the problem of data modeling.
At the conceptual layer, Orm is a method for designing and querying database models. At this layer, applications are described in terms that can be understood by non-technical users. In fact, ORM Data models often obtain more business rules and are easier to verify and upgrade than data models created using other methods. In short, Orm makes data modeling more business-oriented.
Modeling is earlier than design. Traditionally, Orm cannot act as a proxy for E-R models, nor be used to design databases. It is a reasoning model for data storage modeling, just like UML is a reasoning model for Object Modeling. Orm can be used to conceptual specific user ideas to form a general data model. For example, you can sketch a report, and we can create a general data model based on the report information.
The following is the description of the ORM:

• Object role modeling concept
• Usage of Visio During modeling
• Use ORM to create a database
• Finally, I will explain some examples.Code

Concept of ORM

Orm provides a visual representation of data relationships and business rules related to the data. However, it includes not only the chart mode, but also the structured fact language and the process of creating a chart. It is used to improve end users who meet the target application and improve the efficiency of the common unstructured processing process by specifying the data structure to be adopted.
Orm Components

Orm has two formats, and a processing process that enables them to work. The first format is language-based. It allows us to describe data relationships and business rules in an easy-to-understand way. The second format is a chart used to represent the image system.
1. Some basic facts

For example, if we are looking at a phone book, we can describe this data with a full binary relationship. For example:

• This person is named "bill"
• Living on 123 Street"
• "123 Street" in Ohio
• The telephone number is "555-1212".
• The telephone area code for "555-1212" is "614"

The description of this data can be summarized into facts. It is actually the basis of ORM for ordinary workers' phone books.

• Citizen's name
• Residential address of the Citizen
• The address is located in the country
• Citizen's phone number
• Area Number of the phone number

2. Types of facts (declarative statements)

Note that all these basic facts have two terms:
Citizen with name
This is the most common fact type: a binary element.

If a sentence has only one noun, it will be an attribute or a mona1 element. For example, a citizen is male.

There are also three and four elements. For example, a citizen obtains food from Kroger. Here are three nouns.

The number of nouns in fact is called the number of its elements (Arity ). Eventually it will be related to the temple constraints in our database.
This is modeling, and we have not yet entered the design stage. In fact, it is important to achieve the highest efficiency in the modeling process and avoid ing everything to the pre-planned database appearance.
3. Constraints

Most of them are defined in charts, but they are also an important part of the language.
Single constraint: for example, a telephone number has a region code, and a region code can have multiple phone numbers. It is hard to see this in the role relationship, but they usually appear in the chart.
4. Charts

Using an elliptical surrogate noun (diagnosis) and a rectangle to represent the verb (relationship), we can build an intuitive representation of the facts we have already confirmed.