![]() Purchase Quotes: 1 record in the bPurchaseQuote table and one or more records in the bBusinessDocument_ProductLine tables Įvery REAL Business Document has one record in the bBusinessDocument table and depending on the nature of the document, record(s) in the following tables: in a unified way.Īt the "heart" of the entity is the bBusinessDocument table. It is used to support all Sales and Purchase Documents - Quotes, Orders, Shipments, Invoices, Payments etc. The Business Document entity is probably the most unique and complex entity in the Data Models. The table gProductClass, used in v1 for grouping fiunctionality, has been removed from v2.īusiness Document Entity (major changes in v2) In v1 of the Data Models there was NO gProduct_Class table - this is new functionality in v2. Note: all inventory transactions use the gProduct table and its PK - think of the gProduct_Class table as just a "bucket" for common information, grouping and searching. GProduct.sProduct_ClassPK is the FK of the relation between the gProduct_Class and gProduct tables. GProduct.sProductPK is the PK of the gProduct table. GProduct_Class.sProduct_ClassPK is the PK of the gProduct_Class table. These tables create a "one to many structure" connected by PKs and FKs. So a record would first be added for shoe#abc in the gProduct_Class table and many records - for each colour and size - would be added in the gProduct table. It could come in many variations (colours, sizes etc) but all of the variations have the same price. To understand the above, think of a product like a shoe#abc. Įvery product variation has one record in the gProduct_Class table and one record in the gProduct table. The Product entity is a complex entity, used to support Products and their variations in a unified way.Īt the "heart" of the entity is the gProduct_Class table and the gProduct table. You can find more information about the entity in the WX Analysis. "Around" the tables of this entity, are various Dimension tables, connected by FKs. Note: a Party Entity can be a Customer, a Supplier and an Employee at the same time. HEmployee.sPartyFK is the FK of the relation between the gParty and hEmployee tables, but is also the PK of the hEmployee table. PSupplier.sPartyFK is the FK of the relation between the gParty and pSupplier tables, but is also the PK of the pSupplier table. SCustomer.sPartyFK is the FK of the relation between the gParty and sCustomer tables, but is also the PK of the sCustomer table. GParty.sPartyPK is the PK of the gParty table. All these tables create a "star type structure" and are connected by PKs and FKs. Įvery customer, supplier or employee has one record in this table.Ī customer has also a record in the sCustomer table, a supplier a record in the pSupplier table and an employee a record in the hEmployee table. The Party entity is a complex entity, used to support customers, suppliers and employees in a unified way.Īt the "heart" of the entity is the gParty table. This is available in C/S RDBMs (HFSQL C/S, SQL Server etc) but not in Classic HFSQL. To ensure integrity, both the operations - or the set of operations - must be performed, otherwise none.Īn important issue with Transactions is the Isolation Mode of your RDBMs. The classic example is a banking application where we transfer money from one account to another.Īnd Increase the money in another account They are also unicode strings.Ī Transaction is a set of operations - inserts, updates and/or deletions of records in one or more tables either ALL of these operations must be performed or NONE. They are used to "connect" records from one table, with records of another "related" table. Transaction tables - like Inventory, AR, AP and Accounting transactionsīase and Document tables are usually complex entities and Dimension and Transaction tables are simple tables.Ī Primary Key (PK) is a field in a table which uniquely identifies each row (or record) in the table.Īll PKs in the data models are GUIDs - universally unique unicode strings - with a few exceptions.Įvery row (or record) must have a PK, although sometimes it may look stupid to add one.Ī Foreign Key (FK) is a field (or a collection of fields) in one table that uniquely identifies a row of another table. ![]() Tables in the data models are divided into 4 categories:īase tables - like Customers, Products and Contactsĭocument tables - like Invoices, Orders and Shipmentsĭimension tables - like VAT Categories, Colors and Payment terms On the contrary, a Party is a complex entity, because it is represented by many tables (or a view) in the data models. VAT Category is a simple entity, because it is represented by only one table in the data models. The record structure of a table or the "record structure" of a view, is called an entity.Ī Product, a Party and a VAT Category are all entities. Βefore moving on, now is the right time, to introduce some general technical terms, used in the data models and the business applications.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |