เข้าร่วม SAP HANA: ประเภท ไวยากรณ์ และตัวอย่าง

ความหมายของ SAP ฮานะ เข้าร่วมไหม?

A join in SAP HANA combines rows from two or more tables, or from a table and an information view, and returns the values required by the query. Joins are defined graphically in the join node of an information view, and they are also written directly in SQL statements that run on the database.

The two forms are not identical. A join inside a มุมมองการคำนวณ is executed by the SAP HANA calculation engine, which can skip a table when no requested column comes from it, whereas a join written in SAP ฮาน่า SQL is always executed exactly as coded.

The following join types are available when SAP HANA tables and information views are combined.

Referential and text joins are modeling-only types. They exist in the join node of an information view and have no equivalent keyword in SQL, which is why they appear in SAP การสร้างแบบจำลอง HANA tools rather than in a SELECT statement.

SAP HANA Join Syntax and SQL Examples

Inner and outer joins are written in SAP HANA SQL with standard ANSI syntax, so a query tested on another relational database usually runs unchanged. The example below joins a sales order table to a customer table and then to a state table.

SELECT so.ORDER_ID, c.NAME, s.STATE_NAME, so.AMOUNT
FROM SALES_ORDER AS so
INNER JOIN CUSTOMER AS c
  ON so.CUSTOMER_ID = c.CUSTOMER_ID
LEFT OUTER JOIN STATE AS s
  ON c.STATE_CODE = s.STATE_CODE
WHERE so.AMOUNT > 1000
ORDER BY so.ORDER_ID;

The inner join drops every sales order whose customer master record is missing. The left outer join keeps all remaining orders even when the state code has no description, and returns a null state name for those rows. Swapping the two join types therefore changes the row count, not only the columns displayed.

Graphical models reach the same result without SQL. A join node is placed between two data sources in the view editor, the columns that form the join condition are mapped, and the join type and cardinality are set in the node properties. The SAP ฮานะ สตูดิโอ editor and the browser-based modeler both generate the runtime SQL from those settings.

Advanced Join Types in SAP HANA Calculation Views

Calculation views add join behaviour that plain SQL does not express in a single keyword. These options are configured on the join node or through a dedicated node type.

A dynamic join changes the sequence of operations rather than the matching rule. In a static join every defined column takes part in the condition and aggregation happens afterwards; in a dynamic join the unrequested columns are aggregated first, which usually returns fewer rows and a different total. The two therefore answer different business questions, so the flag is set deliberately, not as a general optimization.

How to Choose the Right Join Type in SAP ฮานะ โมเดลลิ่ง

Join selection affects both correctness and runtime, and the fastest join is the one SAP HANA never has to execute. The following rules cover most modeling decisions.

• Referential join — use it only when every row on one side is guaranteed to have a partner, because the engine may omit the join entirely when no column from the joined table is requested.
• การเข้าร่วมภายใน — use it when referential integrity is not guaranteed and unmatched rows must be excluded.
• การรวมภายนอกด้านซ้าย — use it when the first table drives the result and missing master data must still appear.
• การรวมภายนอกแบบเต็ม — use it sparingly, since it is the most expensive option and is rarely required in reporting models.
• Text join — use it whenever a description column depends on the logon language.

Two node properties matter as much as the join type itself. Cardinality (1:1, 1:n, n:1 or n:m) tells the engine how many rows to expect on each side, and the Propose Cardinality function derives it from the data. The Optimize Join Columns flag then allows SAP HANA to remove a join column from the execution plan when the query does not request it. A wrong cardinality can silently multiply measures, so it is verified against the data rather than assumed.

One further constraint shapes new development. Attribute views and analytic views are deprecated, and SAP recommends converting them to graphical calculation views, so a join designed today is normally built in a calculation view join or star join node. Background on the older objects is still useful when an existing model is maintained, and the การดูคุณลักษณะ และ มุมมองเชิงวิเคราะห์ pages describe how those joins were configured. The SAP Learning material on join nodes covers the same behaviour in SAP HANA Cloud, and the wider SAP บทช่วยสอน HANA series explains where information views fit in the platform.

คำถามที่พบบ่อย