Data Model in OFBIZ
About Data Model in OFBIZ
Reference "The Data Model Resource Toolkit" Volumn1, Volumn2 and Some CRMs, the design method in the ERP software, and the Data Model is designed in different subsystems throughout the project. Before you didn't look at Data Model, I think OFBIZ's entity engine is not a very good design. He just played a layer of packaging, there is no great improvement of the practice of writing SQL statements directly, because It uses MAP, which is very easy to make mistakes during the coding phase. Many errors can only be found when they run, and have brought a lot of trouble to the encoders' debugging work. In this regard, there is a big disadvantage than Hibernate and other or mapping tools. And his query is not good enough.
But I think Entity Engine may have a lot of benefits to Data Model's design combination.
Many of our past database design is based on the three field-based, more from the project, designed according to the actual situation, for scalability (by adding field or table) and some need to consider not enough. When Ofbiz's Data Model is integrated into some OO's idea, it is not necessarily suitable for projects, and there is a certain amount of coding workload, and there may be many inquiries and statistics, but refer to OFBIZ's DATA. Model design, can bring some new ideas to our business-based reuse. With the multiplexing of the technical platform, the business is completed, and the completion of the business is based on a solid technical platform. This is what we think for a long time. The new version of Ofbiz3.0 is doing this.
Data Model can also be expressed in a lot of Pattern, which is a simple introduction to the following.
EXTENSIBILITY PATTERN
This is a relatively large one, used in many subsystems, mainly solves the problem of scale and runtime. For an entity table, we may need to three to four related tables. We use Entity to represent the entity table, then we also need EntityClass (optional) EntityType, EntityAttribute, and EntityTypeattr. Their relationship is as follows:
Screen.width / 2) this.width = Screen.width / 2 "vSpace = 2 border = 0>
We assume that the department is designed within the department, the project is engaged in the management department, with the project as an example, the entity is a project table, such as project number, project name, and other fields; EntityType form represents the type of product, such as Software Project (Software_Proj), hardware item (hardware_proj) or consulting service (Service_Proj). Then if a project has only one type, then Entity and EntityType are one-on-one relationship. If a project has several types, such as the Golden Exchange is responsible for hardware and software, then adding EntityClass to represent a pair of relationships, so Saying EntityClass is optional. For different types, there may be some public properties, we can design as the field of EntityType, and we need to record different properties, we have to record different attributes, and we note that there is a HAS_TABLE field in EntityType, indicating this entrytype Record whether there is a special table to record the type. If a recorded HAS_TABLE field is "y", there is a table name with the TYPE field name in the EntityType, indicating this type of information. For example, EntityType, INSERT INTO TABLE EntityType (SEQ, TYPE, HAS_TABLE) VALUES (1, "Hardware_proj", "y" screen.width / 2) this.width = Screen.width / 2 "vSpace = 2 border = 0 >, It means that another table named Hardware_proj is another table to record the specific information of this type. We can see that there is a ParentType in EntityType, which is used to express inheritance, such as we can divide the software item into a trading project, Banking projects, their PARENTTYPE is a software project. The EntityatTR table is better understood, indicating an extension of Entity, an ATTR can represent a column in Entity, such as some Attr's only very few Entity, and also Uncommon, if you don't take into account the fields when you design, you can use this way. EntityTypeattr is an extension to EntityType. Party Patten is based on the extensibility patter, we can consider the design of Party Pattern, here Party refers to participants. We know that many companies are doing the transfer to the customer center. Then a unified customer information is necessary. For example, his supplier is also your own customer, such as a big institution. IBM is our supplier, but we can also do some of their outsourcing projects, or in the future we can do some internal projects for IBM, so they have become our customers. For Party can be divided into personal (Person) and organization (Organization) Two types. The relationship between different party is also intricate, how we will define a clear model becomes more and more important. If recorded in different tables, it may bring inconvenience to future analysis decisions. In the company's interior, inter-employees, different departments, and various roles, the use of traditional methods have also become difficult to define.
Party's design is currently different in different data modeling books, but all as a design. The definition of Party is relatively simple in OFBIZ. By the Party PartyClassification PartyClassificationType PartyType PartyAttribute PartyTypeAttr PartyRole RoleType RoleTypeAttr PartyRelationship PriorityType PartyRelationshipType PartyDataObject PartyGroup Person table, etc. constitute (Note: in the document as well as the Customer table, but the entity does not define the actual investigation, PartyGroup document is not listed). Referring to the original Extensibility Pattern, we can also know roughly every table according to the name. All Party define all Party, all participants are defined in the Party table, regardless of customer, vendors, employees, or others. The Decomposition Type, PartyGroup and Person are two records of HAS_TABLE = '' Y 'in the PartyType table. PartyRole defines the role of Party and the role is defined in Roletype. There is also a little attention to the design, the corresponding permission design, each Party can have multiple UserLogin accounts, and UserLogin and Party are multi-to-one relationship. Small knots have been considered in technology architecture. It is indeed difficult to abstract business, and through some considerations in the design of surface structure, it may be possible to reuse some ideas in business. And I really heard that some domestic companies can realize several levels of technical framework, technical components, business components, business processes, and believe that we can also do it. ------------------------------- Reference document OFBIZ Document: /website/entity-overview.html OFBIZ Data Model
