ਚੁਸਤ DWH ਡਿਜ਼ਾਈਨ ਵਿਧੀਆਂ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ

ਸਟੋਰੇਜ਼ ਸਹੂਲਤ ਦਾ ਵਿਕਾਸ ਕਰਨਾ ਇੱਕ ਲੰਮਾ ਅਤੇ ਗੰਭੀਰ ਕੰਮ ਹੈ।

ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਦੇ ਜੀਵਨ ਵਿੱਚ ਬਹੁਤ ਕੁਝ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਆਬਜੈਕਟ ਮਾਡਲ ਅਤੇ ਬੇਸ ਬਣਤਰ ਨੂੰ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਕਿੰਨੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੋਚਿਆ ਗਿਆ ਹੈ।

ਆਮ ਤੌਰ 'ਤੇ ਸਵੀਕਾਰ ਕੀਤੀ ਗਈ ਪਹੁੰਚ ਸਟਾਰ ਸਕੀਮ ਨੂੰ ਤੀਜੇ ਸਧਾਰਣ ਰੂਪ ਨਾਲ ਜੋੜਨ ਦੇ ਵੱਖ-ਵੱਖ ਰੂਪਾਂ ਨੂੰ ਰਹੀ ਹੈ ਅਤੇ ਰਹਿੰਦੀ ਹੈ। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਸਿਧਾਂਤ ਦੇ ਅਨੁਸਾਰ: ਸ਼ੁਰੂਆਤੀ ਡੇਟਾ - 3NF, ਸ਼ੋਅਕੇਸ - ਸਟਾਰ. ਇਹ ਪਹੁੰਚ, ਸਮੇਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ ਅਤੇ ਖੋਜ ਦੀ ਇੱਕ ਵੱਡੀ ਮਾਤਰਾ ਦੁਆਰਾ ਸਮਰਥਤ, ਪਹਿਲੀ (ਅਤੇ ਕਈ ਵਾਰੀ ਇੱਕੋ ਇੱਕ) ਚੀਜ਼ ਹੈ ਜੋ ਇੱਕ ਤਜਰਬੇਕਾਰ DWH ਮਾਹਰ ਦੇ ਦਿਮਾਗ ਵਿੱਚ ਆਉਂਦੀ ਹੈ ਜਦੋਂ ਇਹ ਸੋਚਦਾ ਹੈ ਕਿ ਇੱਕ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਭੰਡਾਰ ਕਿਸ ਤਰ੍ਹਾਂ ਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਦੂਜੇ ਪਾਸੇ, ਆਮ ਤੌਰ 'ਤੇ ਕਾਰੋਬਾਰ ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ ਗਾਹਕਾਂ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੀਆਂ ਹਨ, ਅਤੇ ਡੇਟਾ "ਡੂੰਘਾਈ ਵਿੱਚ" ਅਤੇ "ਚੌੜਾਈ ਵਿੱਚ" ਦੋਵਾਂ ਵਿੱਚ ਵਾਧਾ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇੱਕ ਤਾਰੇ ਦਾ ਮੁੱਖ ਨੁਕਸਾਨ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ - ਸੀਮਤ ਲਚਕਤਾ.

ਅਤੇ ਜੇਕਰ ਤੁਹਾਡੇ ਸ਼ਾਂਤ ਅਤੇ ਆਰਾਮਦਾਇਕ ਜੀਵਨ ਵਿੱਚ ਇੱਕ DWH ਡਿਵੈਲਪਰ ਵਜੋਂ ਅਚਾਨਕ:

• ਕੰਮ ਪੈਦਾ ਹੋਇਆ "ਘੱਟੋ ਘੱਟ ਕੁਝ ਜਲਦੀ ਕਰਨ ਲਈ, ਅਤੇ ਫਿਰ ਅਸੀਂ ਦੇਖਾਂਗੇ";
• ਹਫ਼ਤੇ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰ ਨਵੇਂ ਸਰੋਤਾਂ ਦੇ ਕਨੈਕਸ਼ਨ ਅਤੇ ਵਪਾਰਕ ਮਾਡਲ ਦੇ ਮੁੜ ਕੰਮ ਕਰਨ ਦੇ ਨਾਲ ਇੱਕ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਾਸਸ਼ੀਲ ਪ੍ਰੋਜੈਕਟ ਪ੍ਰਗਟ ਹੋਇਆ;
• ਇੱਕ ਗਾਹਕ ਪ੍ਰਗਟ ਹੋਇਆ ਹੈ ਜਿਸਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਕਿ ਸਿਸਟਮ ਕਿਸ ਤਰ੍ਹਾਂ ਦਾ ਦਿਖਾਈ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਆਖਿਰਕਾਰ ਇਸਨੂੰ ਕਿਹੜੇ ਫੰਕਸ਼ਨ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਪਰ ਲਗਾਤਾਰ ਇਸਦੇ ਨੇੜੇ ਹੁੰਦੇ ਹੋਏ ਇੱਛਤ ਨਤੀਜੇ ਨੂੰ ਪ੍ਰਯੋਗ ਕਰਨ ਅਤੇ ਲਗਾਤਾਰ ਸੁਧਾਰ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ;
• ਪ੍ਰੋਜੈਕਟ ਮੈਨੇਜਰ ਖੁਸ਼ਖਬਰੀ ਦੇ ਨਾਲ ਅੰਦਰ ਆ ਗਿਆ: "ਅਤੇ ਹੁਣ ਸਾਡੇ ਕੋਲ ਚੁਸਤ ਹੈ!"

ਜਾਂ ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ ਇਹ ਪਤਾ ਕਰਨ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਸਟੋਰੇਜ ਦੀਆਂ ਸਹੂਲਤਾਂ ਕਿਵੇਂ ਬਣਾ ਸਕਦੇ ਹੋ - ਕੱਟ ਵਿੱਚ ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ!

"ਲਚਕਤਾ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ?

ਪਹਿਲਾਂ, ਆਓ ਪਰਿਭਾਸ਼ਿਤ ਕਰੀਏ ਕਿ "ਲਚਕੀਲੇ" ਕਹੇ ਜਾਣ ਲਈ ਸਿਸਟਮ ਵਿੱਚ ਕਿਹੜੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਇਹ ਵਰਣਨ ਯੋਗ ਹੈ ਕਿ ਵਰਣਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਖਾਸ ਤੌਰ 'ਤੇ ਸੰਬੰਧਿਤ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਸਿਸਟਮ, ਨਾ ਕਰਨ ਲਈ ਪ੍ਰਕਿਰਿਆ ਇਸ ਦੇ ਵਿਕਾਸ. ਇਸ ਲਈ, ਜੇ ਤੁਸੀਂ ਵਿਕਾਸ ਵਿਧੀ ਦੇ ਤੌਰ 'ਤੇ ਐਗਾਇਲ ਬਾਰੇ ਪੜ੍ਹਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਹੋਰ ਲੇਖ ਪੜ੍ਹਨਾ ਬਿਹਤਰ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਉਥੇ ਹੀ, ਹੈਬਰੇ 'ਤੇ, ਬਹੁਤ ਸਾਰੀਆਂ ਦਿਲਚਸਪ ਸਮੱਗਰੀਆਂ ਹਨ (ਜਿਵੇਂ ਸਮੀਖਿਆ и ਵਿਹਾਰਕ, ਅਤੇ ਸਮੱਸਿਆ ਵਾਲਾ).

ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਡੇਟਾ ਵੇਅਰਹਾਊਸ ਦੀ ਬਣਤਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਸਬੰਧਤ ਨਹੀਂ ਹਨ। ਕੁੱਲ ਮਿਲਾ ਕੇ, ਇੱਕ ਚੁਸਤ ਆਰਕੀਟੈਕਚਰ ਲਈ ਇੱਕ ਚੁਸਤ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਵਿਕਸਤ ਕਰਨਾ ਬਹੁਤ ਸੌਖਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਅਭਿਆਸ ਵਿੱਚ, ਕਿਮਬਲ ਅਤੇ ਡੇਟਾਵਾਲਟ ਦੇ ਅਨੁਸਾਰ ਕਲਾਸਿਕ ਡੀਡਬਲਯੂਐਚ ਦੇ ਚੁਸਤ ਵਿਕਾਸ ਦੇ ਨਾਲ ਅਕਸਰ ਵਿਕਲਪ ਹੁੰਦੇ ਹਨ - ਵਾਟਰਫਾਲ ਦੇ ਅਨੁਸਾਰ, ਇੱਕ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਇਸਦੇ ਦੋ ਰੂਪਾਂ ਵਿੱਚ ਲਚਕਤਾ ਦੇ ਖੁਸ਼ਹਾਲ ਸੰਜੋਗ ਨਾਲੋਂ.

ਇਸ ਲਈ, ਲਚਕਦਾਰ ਸਟੋਰੇਜ ਵਿੱਚ ਕਿਹੜੀਆਂ ਸਮਰੱਥਾਵਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ? ਇੱਥੇ ਤਿੰਨ ਨੁਕਤੇ ਹਨ:

1. ਜਲਦੀ ਸਪੁਰਦਗੀ ਅਤੇ ਤੇਜ਼ ਤਬਦੀਲੀ - ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਪਹਿਲਾ ਕਾਰੋਬਾਰੀ ਨਤੀਜਾ (ਉਦਾਹਰਨ ਲਈ, ਪਹਿਲੀ ਕਾਰਜਕਾਰੀ ਰਿਪੋਰਟਾਂ) ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਭਾਵ, ਪੂਰੀ ਪ੍ਰਣਾਲੀ ਦੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਅਤੇ ਲਾਗੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਹਰੇਕ ਅਗਲੀ ਸੰਸ਼ੋਧਨ ਨੂੰ ਵੀ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਘੱਟ ਸਮਾਂ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ।
2. ਦੁਹਰਾਉ ਸੁਧਾਈ - ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰੇਕ ਬਾਅਦ ਵਿੱਚ ਸੁਧਾਰ ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਤੋਂ ਕੰਮ ਕਰ ਰਹੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਉਹ ਪਲ ਹੈ ਜੋ ਅਕਸਰ ਵੱਡੇ ਪ੍ਰੋਜੈਕਟਾਂ 'ਤੇ ਸਭ ਤੋਂ ਵੱਡਾ ਸੁਪਨਾ ਬਣ ਜਾਂਦਾ ਹੈ - ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ, ਵਿਅਕਤੀਗਤ ਵਸਤੂਆਂ ਇੰਨੇ ਕੁ ਕੁਨੈਕਸ਼ਨਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਮੌਜੂਦਾ ਟੇਬਲ ਵਿੱਚ ਇੱਕ ਖੇਤਰ ਜੋੜਨ ਦੀ ਬਜਾਏ ਨੇੜੇ ਦੀ ਇੱਕ ਕਾਪੀ ਵਿੱਚ ਤਰਕ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੁਹਰਾਉਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਜੇ ਤੁਸੀਂ ਹੈਰਾਨ ਹੋ ਕਿ ਮੌਜੂਦਾ ਵਸਤੂਆਂ 'ਤੇ ਸੁਧਾਰਾਂ ਦੇ ਪ੍ਰਭਾਵ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਵਿੱਚ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸੁਧਾਰਾਂ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਅਜੇ ਤੱਕ ਬੈਂਕਿੰਗ ਜਾਂ ਟੈਲੀਕਾਮ ਵਿੱਚ ਵੱਡੇ ਡੇਟਾ ਵੇਅਰਹਾਊਸਾਂ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕੀਤਾ ਹੈ।
3. ਵਪਾਰਕ ਲੋੜਾਂ ਨੂੰ ਬਦਲਣ ਲਈ ਲਗਾਤਾਰ ਅਨੁਕੂਲ ਹੋਣਾ - ਸਮੁੱਚੀ ਵਸਤੂ ਬਣਤਰ ਨੂੰ ਸਿਰਫ਼ ਸੰਭਾਵੀ ਵਿਸਤਾਰ ਨੂੰ ਧਿਆਨ ਵਿਚ ਰੱਖਦੇ ਹੋਏ ਹੀ ਨਹੀਂ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਇਸ ਉਮੀਦ ਦੇ ਨਾਲ ਕਿ ਇਸ ਅਗਲੇ ਵਿਸਥਾਰ ਦੀ ਦਿਸ਼ਾ ਦਾ ਡਿਜ਼ਾਈਨ ਪੜਾਅ 'ਤੇ ਸੁਪਨਾ ਵੀ ਨਹੀਂ ਲਿਆ ਜਾ ਸਕਦਾ ਸੀ।

ਅਤੇ ਹਾਂ, ਇਹਨਾਂ ਸਾਰੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਇੱਕ ਸਿਸਟਮ ਵਿੱਚ ਪੂਰਾ ਕਰਨਾ ਸੰਭਵ ਹੈ (ਬੇਸ਼ਕ, ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ ਅਤੇ ਕੁਝ ਰਿਜ਼ਰਵੇਸ਼ਨਾਂ ਦੇ ਨਾਲ)।

ਹੇਠਾਂ ਮੈਂ ਡਾਟਾ ਵੇਅਰਹਾਊਸਾਂ ਲਈ ਦੋ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਚੁਸਤ ਡਿਜ਼ਾਈਨ ਵਿਧੀਆਂ 'ਤੇ ਵਿਚਾਰ ਕਰਾਂਗਾ - ਐਂਕਰ ਮਾਡਲ и ਡਾਟਾ ਵਾਲਟ. ਬਰੈਕਟਾਂ ਤੋਂ ਬਾਹਰ ਛੱਡੀਆਂ ਅਜਿਹੀਆਂ ਸ਼ਾਨਦਾਰ ਤਕਨੀਕਾਂ ਹਨ ਜਿਵੇਂ ਕਿ, EAV, 6NF (ਇਸਦੇ ਸ਼ੁੱਧ ਰੂਪ ਵਿੱਚ) ਅਤੇ NoSQL ਹੱਲਾਂ ਨਾਲ ਸਬੰਧਤ ਹਰ ਚੀਜ਼ - ਇਸ ਲਈ ਨਹੀਂ ਕਿ ਉਹ ਕਿਸੇ ਤਰ੍ਹਾਂ ਮਾੜੇ ਹਨ, ਅਤੇ ਇਸ ਲਈ ਵੀ ਨਹੀਂ ਕਿ ਇਸ ਕੇਸ ਵਿੱਚ ਲੇਖ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਧਮਕੀ ਦੇਵੇਗਾ। ਔਸਤ ਡਿਸਸਰ ਦੀ ਮਾਤਰਾ. ਇਹ ਸਿਰਫ ਇਹ ਹੈ ਕਿ ਇਹ ਸਭ ਕੁਝ ਥੋੜੀ ਵੱਖਰੀ ਸ਼੍ਰੇਣੀ ਦੇ ਹੱਲਾਂ ਨਾਲ ਸਬੰਧਤ ਹੈ - ਜਾਂ ਤਾਂ ਉਹਨਾਂ ਤਕਨੀਕਾਂ ਨਾਲ ਜੋ ਤੁਸੀਂ ਖਾਸ ਮਾਮਲਿਆਂ ਵਿੱਚ ਵਰਤ ਸਕਦੇ ਹੋ, ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸਮੁੱਚੀ ਆਰਕੀਟੈਕਚਰ (ਜਿਵੇਂ ਕਿ EAV) ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ, ਜਾਂ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਹੋਰ ਜਾਣਕਾਰੀ ਸਟੋਰੇਜ ਪੈਰਾਡਾਈਮ (ਜਿਵੇਂ ਕਿ ਗ੍ਰਾਫ ਡੇਟਾਬੇਸ) ਨਾਲ। ਅਤੇ ਹੋਰ ਵਿਕਲਪ NoSQL)।

"ਕਲਾਸੀਕਲ" ਪਹੁੰਚ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਲਚਕਦਾਰ ਵਿਧੀਆਂ ਵਿੱਚ ਉਹਨਾਂ ਦੇ ਹੱਲ

"ਕਲਾਸੀਕਲ" ਪਹੁੰਚ ਦੁਆਰਾ ਮੇਰਾ ਮਤਲਬ ਚੰਗਾ ਪੁਰਾਣਾ ਤਾਰਾ ਹੈ (ਅੰਡਰਲਾਈੰਗ ਲੇਅਰਾਂ ਦੇ ਖਾਸ ਲਾਗੂ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਕਿਮਬਾਲ, ਇਨਮੋਨ ਅਤੇ ਸੀਡੀਐਮ ਦੇ ਪੈਰੋਕਾਰ ਮੈਨੂੰ ਮਾਫ਼ ਕਰ ਸਕਦੇ ਹਨ)।

1. ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਸਖ਼ਤ ਮੁੱਖਤਾ

ਇਹ ਮਾਡਲ ਡੇਟਾ ਦੀ ਸਪਸ਼ਟ ਵੰਡ 'ਤੇ ਅਧਾਰਤ ਹੈ ਮਾਪ и ਤੱਥ. ਅਤੇ ਇਹ, ਲਾਹਨਤ, ਲਾਜ਼ੀਕਲ ਹੈ - ਆਖਰਕਾਰ, ਬਹੁਤ ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਡੇਟਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੁਝ ਭਾਗਾਂ (ਆਯਾਮਾਂ) ਵਿੱਚ ਕੁਝ ਸੰਖਿਆਤਮਕ ਸੂਚਕਾਂ (ਤੱਥਾਂ) ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਹੇਠਾਂ ਆਉਂਦਾ ਹੈ।

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇੱਕ ਵਿਦੇਸ਼ੀ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਟੇਬਲਾਂ ਵਿਚਕਾਰ ਸਬੰਧਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਵਸਤੂਆਂ ਦੇ ਵਿਚਕਾਰ ਸਬੰਧ ਸਥਾਪਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਇਹ ਕਾਫ਼ੀ ਕੁਦਰਤੀ ਲੱਗਦਾ ਹੈ, ਪਰ ਤੁਰੰਤ ਲਚਕਤਾ ਦੀ ਪਹਿਲੀ ਸੀਮਾ ਵੱਲ ਖੜਦਾ ਹੈ - ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਮੁੱਖਤਾ ਦੀ ਸਖਤ ਪਰਿਭਾਸ਼ਾ.

ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟੇਬਲ ਡਿਜ਼ਾਈਨ ਪੜਾਅ 'ਤੇ, ਤੁਹਾਨੂੰ ਸੰਬੰਧਿਤ ਵਸਤੂਆਂ ਦੇ ਹਰੇਕ ਜੋੜੇ ਲਈ ਸਹੀ ਢੰਗ ਨਾਲ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਉਹ ਕਈ-ਤੋਂ-ਬਹੁਤ, ਜਾਂ ਸਿਰਫ 1-ਤੋਂ-ਕਈ, ਅਤੇ "ਕਿਹੜੀ ਦਿਸ਼ਾ ਵਿੱਚ" ਹਨ। ਇਹ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਸਾਰਣੀ ਵਿੱਚ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਹੋਵੇਗੀ ਅਤੇ ਕਿਸ ਕੋਲ ਵਿਦੇਸ਼ੀ ਕੁੰਜੀ ਹੋਵੇਗੀ। ਜਦੋਂ ਨਵੀਆਂ ਲੋੜਾਂ ਪ੍ਰਾਪਤ ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ ਇਸ ਰਵੱਈਏ ਨੂੰ ਬਦਲਣਾ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਅਧਾਰ ਨੂੰ ਦੁਬਾਰਾ ਕੰਮ ਕਰਨ ਵੱਲ ਲੈ ਜਾਵੇਗਾ।

ਉਦਾਹਰਨ ਲਈ, "ਨਕਦੀ ਰਸੀਦ" ਵਸਤੂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਸਮੇਂ, ਤੁਸੀਂ, ਵਿਕਰੀ ਵਿਭਾਗ ਦੀਆਂ ਸਹੁੰਆਂ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹੋਏ, ਕਾਰਵਾਈ ਦੀ ਸੰਭਾਵਨਾ ਨਿਰਧਾਰਤ ਕੀਤੀ ਸੀ ਕਈ ਚੈੱਕ ਅਹੁਦਿਆਂ ਲਈ ਇੱਕ ਤਰੱਕੀ (ਪਰ ਇਸਦੇ ਉਲਟ ਨਹੀਂ):

ਅਤੇ ਕੁਝ ਸਮੇਂ ਬਾਅਦ, ਸਹਿਕਰਮੀਆਂ ਨੇ ਇੱਕ ਨਵੀਂ ਮਾਰਕੀਟਿੰਗ ਰਣਨੀਤੀ ਪੇਸ਼ ਕੀਤੀ ਜਿਸ ਵਿੱਚ ਉਹ ਉਸੇ ਸਥਿਤੀ 'ਤੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ ਇੱਕੋ ਸਮੇਂ ਕਈ ਤਰੱਕੀਆਂ. ਅਤੇ ਹੁਣ ਤੁਹਾਨੂੰ ਰਿਸ਼ਤੇ ਨੂੰ ਇੱਕ ਵੱਖਰੀ ਵਸਤੂ ਵਿੱਚ ਵੱਖ ਕਰਕੇ ਟੇਬਲ ਨੂੰ ਸੋਧਣ ਦੀ ਲੋੜ ਹੈ।

(ਸਾਰੀਆਂ ਪ੍ਰਾਪਤ ਕੀਤੀਆਂ ਵਸਤੂਆਂ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਪ੍ਰੋਮੋਸ਼ਨ ਜਾਂਚ ਸ਼ਾਮਲ ਕੀਤੀ ਗਈ ਹੈ ਹੁਣ ਵੀ ਸੁਧਾਰ ਕੀਤੇ ਜਾਣ ਦੀ ਲੋੜ ਹੈ)।

ਡੇਟਾ ਵਾਲਟ ਅਤੇ ਐਂਕਰ ਮਾਡਲ ਵਿੱਚ ਰਿਸ਼ਤੇ

ਇਸ ਸਥਿਤੀ ਤੋਂ ਬਚਣਾ ਕਾਫ਼ੀ ਸਰਲ ਸਾਬਤ ਹੋਇਆ: ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਕਰਨ ਲਈ ਵਿਕਰੀ ਵਿਭਾਗ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ। ਸਾਰੇ ਕੁਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਵਿੱਚ ਵੱਖਰੇ ਟੇਬਲ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇਸ 'ਤੇ ਕਈ-ਤੋਂ-ਕਈਆਂ ਦੇ ਰੂਪ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕਰੋ।

ਇਹ ਪਹੁੰਚ ਪ੍ਰਸਤਾਵਿਤ ਸੀ ਡੈਨ ਲਿਨਸਟੇਡ ਪੈਰਾਡਾਈਮ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਡਾਟਾ ਵਾਲਟ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਰਥਿਤ ਹੈ ਲਾਰਸ ਰੋਨਬੈਕ в ਐਂਕਰ ਮਾਡਲ.

ਨਤੀਜੇ ਵਜੋਂ, ਸਾਨੂੰ ਲਚਕਦਾਰ ਵਿਧੀਆਂ ਦੀ ਪਹਿਲੀ ਵਿਸ਼ੇਸ਼ ਵਿਸ਼ੇਸ਼ਤਾ ਮਿਲਦੀ ਹੈ:

ਵਸਤੂਆਂ ਦੇ ਵਿਚਕਾਰ ਸਬੰਧ ਮੂਲ ਇਕਾਈਆਂ ਦੇ ਗੁਣਾਂ ਵਿੱਚ ਸਟੋਰ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਇੱਕ ਵੱਖਰੀ ਕਿਸਮ ਦੀ ਵਸਤੂ ਹਨ।

В ਡਾਟਾ ਵਾਲਟ ਅਜਿਹੀਆਂ ਲਿੰਕਿੰਗ ਟੇਬਲਾਂ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਲਿੰਕਅਤੇ ਅੰਦਰ ਐਂਕਰ ਮਾਡਲ - ਟਾਈ. ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ, ਉਹ ਬਹੁਤ ਸਮਾਨ ਹਨ, ਹਾਲਾਂਕਿ ਉਹਨਾਂ ਦੇ ਅੰਤਰ ਨਾਮ ਨਾਲ ਖਤਮ ਨਹੀਂ ਹੁੰਦੇ (ਜਿਸ ਬਾਰੇ ਹੇਠਾਂ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ). ਦੋਵੇਂ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ, ਲਿੰਕ ਟੇਬਲ ਲਿੰਕ ਕਰ ਸਕਦੇ ਹਨ ਸੰਸਥਾਵਾਂ ਦੀ ਕੋਈ ਵੀ ਗਿਣਤੀ (ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ 2)।

ਇਹ ਰਿਡੰਡੈਂਸੀ, ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ, ਸੋਧਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਲਚਕਤਾ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। ਅਜਿਹਾ ਢਾਂਚਾ ਨਾ ਸਿਰਫ ਮੌਜੂਦਾ ਲਿੰਕਾਂ ਦੀ ਮੁੱਖਤਾ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਲਈ, ਸਗੋਂ ਨਵੇਂ ਜੋੜਨ ਲਈ ਵੀ ਸਹਿਣਸ਼ੀਲ ਬਣ ਜਾਂਦਾ ਹੈ - ਜੇ ਹੁਣ ਇੱਕ ਚੈੱਕ ਸਥਿਤੀ ਵਿੱਚ ਕੈਸ਼ੀਅਰ ਨਾਲ ਵੀ ਇੱਕ ਲਿੰਕ ਹੈ ਜਿਸ ਨੇ ਇਸ ਨੂੰ ਤੋੜਿਆ ਹੈ, ਤਾਂ ਅਜਿਹੇ ਲਿੰਕ ਦੀ ਦਿੱਖ ਸਿਰਫ਼ ਹੋਵੇਗੀ. ਕਿਸੇ ਵੀ ਮੌਜੂਦਾ ਵਸਤੂਆਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤੇ ਬਿਨਾਂ ਮੌਜੂਦਾ ਟੇਬਲ ਉੱਤੇ ਇੱਕ ਐਡ-ਆਨ ਬਣੋ।

2. ਡਾਟਾ ਡੁਪਲੀਕੇਸ਼ਨ

ਲਚਕਦਾਰ ਆਰਕੀਟੈਕਚਰ ਦੁਆਰਾ ਹੱਲ ਕੀਤੀ ਗਈ ਦੂਜੀ ਸਮੱਸਿਆ ਘੱਟ ਸਪੱਸ਼ਟ ਹੈ ਅਤੇ ਪਹਿਲੀ ਥਾਂ ਵਿੱਚ ਨਿਹਿਤ ਹੈ। SCD2 ਕਿਸਮ ਦੇ ਮਾਪ (ਹੌਲੀ-ਹੌਲੀ ਦੂਜੀ ਕਿਸਮ ਦੇ ਮਾਪ ਬਦਲ ਰਹੇ ਹਨ), ਹਾਲਾਂਕਿ ਸਿਰਫ ਉਹ ਹੀ ਨਹੀਂ।

ਇੱਕ ਕਲਾਸਿਕ ਵੇਅਰਹਾਊਸ ਵਿੱਚ, ਇੱਕ ਮਾਪ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਾਰਣੀ ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਸਰੋਗੇਟ ਕੁੰਜੀ (ਇੱਕ PK ਵਜੋਂ) ਅਤੇ ਵੱਖਰੇ ਕਾਲਮਾਂ ਵਿੱਚ ਵਪਾਰਕ ਕੁੰਜੀਆਂ ਅਤੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਹੁੰਦਾ ਹੈ।

ਜੇਕਰ ਕੋਈ ਮਾਪ ਸੰਸਕਰਣ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਸੰਸਕਰਣ ਵੈਧਤਾ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਖੇਤਰਾਂ ਦੇ ਮਿਆਰੀ ਸਮੂਹ ਵਿੱਚ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਸਰੋਤ ਵਿੱਚ ਇੱਕ ਕਤਾਰ ਲਈ ਕਈ ਸੰਸਕਰਣ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ (ਵਰਜਨਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਹਰੇਕ ਤਬਦੀਲੀ ਲਈ ਇੱਕ)।

ਜੇਕਰ ਇੱਕ ਅਯਾਮ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰ-ਵਾਰ ਬਦਲਦੇ ਹੋਏ ਸੰਸਕਰਣ ਗੁਣ ਸ਼ਾਮਲ ਹਨ, ਤਾਂ ਅਜਿਹੇ ਆਯਾਮ ਦੇ ਸੰਸਕਰਣਾਂ ਦੀ ਸੰਖਿਆ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋਵੇਗੀ (ਭਾਵੇਂ ਕਿ ਬਾਕੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸੰਸਕਰਨਿਤ ਨਹੀਂ ਹਨ ਜਾਂ ਕਦੇ ਨਹੀਂ ਬਦਲਦੀਆਂ ਹਨ), ਅਤੇ ਜੇਕਰ ਅਜਿਹੇ ਕਈ ਗੁਣ ਹਨ, ਤਾਂ ਸੰਸਕਰਣਾਂ ਦੀ ਸੰਖਿਆ ਉਹਨਾਂ ਦੀ ਗਿਣਤੀ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਵਧੋ। ਇਹ ਮਾਪ ਡਿਸਕ ਸਪੇਸ ਦੀ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਮਾਤਰਾ ਲੈ ਸਕਦਾ ਹੈ, ਹਾਲਾਂਕਿ ਇਸ ਦੁਆਰਾ ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਬਹੁਤ ਸਾਰਾ ਡਾਟਾ ਦੂਜੀਆਂ ਕਤਾਰਾਂ ਤੋਂ ਅਟੱਲ ਵਿਸ਼ੇਸ਼ਤਾ ਮੁੱਲਾਂ ਦੀ ਡੁਪਲੀਕੇਟ ਹੈ।

ਇਸ ਦੇ ਨਾਲ ਹੀ, ਇਸਦੀ ਵਰਤੋਂ ਅਕਸਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਸਧਾਰਨਕਰਨ - ਕੁਝ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਇੱਕ ਮੁੱਲ ਵਜੋਂ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਹਵਾਲਾ ਕਿਤਾਬ ਜਾਂ ਕਿਸੇ ਹੋਰ ਮਾਪ ਦੇ ਲਿੰਕ ਵਜੋਂ। ਇਹ ਪਹੁੰਚ ਡੇਟਾ ਐਕਸੈਸ ਨੂੰ ਤੇਜ਼ ਕਰਦੀ ਹੈ, ਇੱਕ ਮਾਪ ਨੂੰ ਐਕਸੈਸ ਕਰਨ ਵੇਲੇ ਜੁੜਨ ਦੀ ਗਿਣਤੀ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ।

ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਦੀ ਅਗਵਾਈ ਕਰਦਾ ਹੈ ਇੱਕੋ ਜਾਣਕਾਰੀ ਨੂੰ ਕਈ ਥਾਵਾਂ 'ਤੇ ਇੱਕੋ ਸਮੇਂ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਰਿਹਾਇਸ਼ ਦੇ ਖੇਤਰ ਅਤੇ ਗਾਹਕ ਦੀ ਸ਼੍ਰੇਣੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਇੱਕੋ ਸਮੇਂ "ਗਾਹਕ" ਮਾਪ ਅਤੇ "ਖਰੀਦ", "ਡਿਲੀਵਰੀ" ਅਤੇ "ਕਾਲ ਸੈਂਟਰ ਕਾਲਾਂ" ਤੱਥਾਂ ਦੇ ਨਾਲ-ਨਾਲ "ਕਲਾਇੰਟ - ਕਲਾਇੰਟ ਮੈਨੇਜਰ" ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। "ਲਿੰਕ ਸਾਰਣੀ.

ਆਮ ਤੌਰ 'ਤੇ, ਉਪਰੋਕਤ ਵਰਣਿਤ ਨਿਯਮਤ (ਗੈਰ-ਸੰਸਕਰਣ ਵਾਲੇ) ਮਾਪਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਪਰ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਉਹਨਾਂ ਦਾ ਇੱਕ ਵੱਖਰਾ ਪੈਮਾਨਾ ਹੋ ਸਕਦਾ ਹੈ: ਕਿਸੇ ਵਸਤੂ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣ ਦੀ ਦਿੱਖ (ਖਾਸ ਤੌਰ 'ਤੇ ਪਿਛਾਂਹ-ਖਿੱਚੂ) ਨਾ ਸਿਰਫ ਸਾਰੇ ਸਬੰਧਤਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ। ਟੇਬਲ, ਪਰ ਸੰਬੰਧਿਤ ਵਸਤੂਆਂ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣਾਂ ਦੀ ਦਿੱਖ ਲਈ - ਜਦੋਂ ਟੇਬਲ 1 ਦੀ ਵਰਤੋਂ ਟੇਬਲ 2 ਨੂੰ ਬਣਾਉਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਟੇਬਲ 2 ਦੀ ਵਰਤੋਂ ਸਾਰਣੀ 3, ਆਦਿ ਨੂੰ ਬਣਾਉਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਭਾਵੇਂ ਸਾਰਣੀ 1 ਦੇ ਨਿਰਮਾਣ ਵਿੱਚ ਸਾਰਣੀ 3 ਦੀ ਇੱਕ ਵੀ ਵਿਸ਼ੇਸ਼ਤਾ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ (ਅਤੇ ਹੋਰ ਸਰੋਤਾਂ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਗਈ ਸਾਰਣੀ 2 ਦੀਆਂ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ਾਮਲ ਹਨ), ਇਸ ਨਿਰਮਾਣ ਨੂੰ ਸੰਸਕਰਣ ਕਰਨ ਨਾਲ ਘੱਟੋ ਘੱਟ ਵਾਧੂ ਓਵਰਹੈੱਡ ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਵਾਧੂ ਸਾਰਣੀ 3 ਵਿੱਚ ਸੰਸਕਰਣ। ਜਿਸਦਾ ਇਸ ਨਾਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਹੋਰ ਹੇਠਾਂ ਚੇਨ।

3. ਰੀਵਰਕ ਦੀ ਗੈਰ-ਰੇਖਿਕ ਜਟਿਲਤਾ

ਉਸੇ ਸਮੇਂ, ਕਿਸੇ ਹੋਰ ਦੇ ਆਧਾਰ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਹਰੇਕ ਨਵਾਂ ਸਟੋਰਫਰੰਟ ਉਹਨਾਂ ਸਥਾਨਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ETL ਵਿੱਚ ਬਦਲਾਅ ਕੀਤੇ ਜਾਣ 'ਤੇ ਡੇਟਾ "ਡਾਵਰਜ" ਹੋ ਸਕਦਾ ਹੈ। ਇਹ, ਬਦਲੇ ਵਿੱਚ, ਹਰੇਕ ਅਗਲੀ ਸੰਸ਼ੋਧਨ ਦੀ ਜਟਿਲਤਾ (ਅਤੇ ਮਿਆਦ) ਵਿੱਚ ਵਾਧਾ ਕਰਦਾ ਹੈ।

ਜੇ ਉਪਰੋਕਤ ਬਹੁਤ ਘੱਟ ਸੋਧੀਆਂ ETL ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਾਲੇ ਸਿਸਟਮਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅਜਿਹੇ ਪੈਰਾਡਾਈਮ ਵਿੱਚ ਰਹਿ ਸਕਦੇ ਹੋ - ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਸਾਰੀਆਂ ਸਬੰਧਤ ਵਸਤੂਆਂ ਲਈ ਨਵੇਂ ਸੋਧਾਂ ਸਹੀ ਢੰਗ ਨਾਲ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਜੇਕਰ ਸੰਸ਼ੋਧਨ ਅਕਸਰ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਅਚਾਨਕ ਕਈ ਕੁਨੈਕਸ਼ਨਾਂ ਦੇ "ਗੁੰਮ" ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਕਾਫ਼ੀ ਵੱਧ ਜਾਂਦੀ ਹੈ।

ਜੇਕਰ, ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਇਸ ਗੱਲ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹਾਂ ਕਿ "ਸੰਸਕਰਣ" ETL "ਗੈਰ-ਸੰਸਕਰਣ" ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ ਹੈ, ਤਾਂ ਇਸ ਸਮੁੱਚੀ ਸਹੂਲਤ ਨੂੰ ਅਕਸਰ ਅਪਡੇਟ ਕਰਦੇ ਸਮੇਂ ਗਲਤੀਆਂ ਤੋਂ ਬਚਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।

ਡਾਟਾ ਵਾਲਟ ਅਤੇ ਐਂਕਰ ਮਾਡਲ ਵਿੱਚ ਵਸਤੂਆਂ ਅਤੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ

ਲਚਕਦਾਰ ਆਰਕੀਟੈਕਚਰ ਦੇ ਲੇਖਕਾਂ ਦੁਆਰਾ ਪ੍ਰਸਤਾਵਿਤ ਪਹੁੰਚ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਤਿਆਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

ਇਸ ਨੂੰ ਵੱਖ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਤਬਦੀਲੀਆਂ ਇੱਕੋ ਜਿਹੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ। ਅਰਥਾਤ, ਕੁੰਜੀਆਂ ਨੂੰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਤੋਂ ਵੱਖਰਾ ਸਟੋਰ ਕਰੋ।

ਹਾਲਾਂਕਿ, ਕਿਸੇ ਨੂੰ ਉਲਝਣ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਸੰਸਕਰਣ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਦੇ ਨਾਲ ਗੁਣ ਨਾ ਬਦਲਿਆ: ਪਹਿਲਾ ਇਸਦੀਆਂ ਤਬਦੀਲੀਆਂ ਦੇ ਇਤਿਹਾਸ ਨੂੰ ਸਟੋਰ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਪਰ ਬਦਲ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਣ ਵਜੋਂ, ਜਦੋਂ ਇੱਕ ਇਨਪੁਟ ਗਲਤੀ ਨੂੰ ਠੀਕ ਕਰਨਾ ਜਾਂ ਨਵਾਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨਾ); ਦੂਜਾ ਕਦੇ ਨਹੀਂ ਬਦਲਦਾ।

ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਇਸ ਗੱਲ 'ਤੇ ਵੱਖਰੇ ਹਨ ਕਿ ਡੇਟਾ ਵਾਲਟ ਅਤੇ ਐਂਕਰ ਮਾਡਲ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਇੱਕ ਆਰਕੀਟੈਕਚਰਲ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਡਾਟਾ ਵਾਲਟਨੂੰ ਬਦਲਿਆ ਨਹੀਂ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕੁੰਜੀਆਂ ਦਾ ਪੂਰਾ ਸੈੱਟ - ਕੁਦਰਤੀ (ਸੰਸਥਾ ਦਾ TIN, ਸਰੋਤ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਉਤਪਾਦ ਕੋਡ, ਆਦਿ) ਅਤੇ ਸਰੋਗੇਟ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਬਾਕੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸਰੋਤ ਅਤੇ/ਜਾਂ ਤਬਦੀਲੀਆਂ ਦੀ ਬਾਰੰਬਾਰਤਾ ਦੇ ਅਨੁਸਾਰ ਸਮੂਹਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਹਰੇਕ ਸਮੂਹ ਲਈ ਇੱਕ ਵੱਖਰੀ ਸਾਰਣੀ ਬਣਾਈ ਰੱਖੋ ਸੰਸਕਰਣਾਂ ਦੇ ਇੱਕ ਸੁਤੰਤਰ ਸਮੂਹ ਦੇ ਨਾਲ.

ਪੈਰਾਡਾਈਮ ਵਿੱਚ ਐਂਕਰ ਮਾਡਲ ਬਦਲਿਆ ਨਹੀਂ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਸਿਰਫ਼ ਸਰੋਗੇਟ ਕੁੰਜੀ ਸਾਰ ਬਾਕੀ ਸਭ ਕੁਝ (ਕੁਦਰਤੀ ਕੁੰਜੀਆਂ ਸਮੇਤ) ਇਸਦੇ ਗੁਣਾਂ ਦਾ ਸਿਰਫ਼ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਮਾਮਲਾ ਹੈ। ਜਿਸ ਵਿੱਚ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਮੂਲ ਰੂਪ ਵਿੱਚ ਇੱਕ ਦੂਜੇ ਤੋਂ ਸੁਤੰਤਰ ਹੁੰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਹਰੇਕ ਵਿਸ਼ੇਸ਼ਤਾ ਲਈ a ਵੱਖਰੀ ਸਾਰਣੀ.

В ਡਾਟਾ ਵਾਲਟ ਇਕਾਈ ਕੁੰਜੀਆਂ ਵਾਲੀਆਂ ਟੇਬਲਾਂ ਨੂੰ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ ਹੁਬਾਮੀ. ਹੱਬ ਵਿੱਚ ਹਮੇਸ਼ਾ ਖੇਤਰਾਂ ਦਾ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੂਹ ਹੁੰਦਾ ਹੈ:

• ਕੁਦਰਤੀ ਹਸਤੀ ਕੁੰਜੀਆਂ
• ਸਰੋਗੇਟ ਕੁੰਜੀ
• ਸਰੋਤ ਨਾਲ ਲਿੰਕ
• ਜੋੜਨ ਦਾ ਸਮਾਂ ਰਿਕਾਰਡ ਕਰੋ

ਹੱਬ ਵਿੱਚ ਪੋਸਟਾਂ ਕਦੇ ਨਹੀਂ ਬਦਲਦਾ ਅਤੇ ਨਾ ਹੀ ਕੋਈ ਸੰਸਕਰਣ ਹੈ. ਬਾਹਰੀ ਤੌਰ 'ਤੇ, ਹੱਬ ਸਰੋਗੇਟਸ ਬਣਾਉਣ ਲਈ ਕੁਝ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਆਈਡੀ-ਮੈਪ ਕਿਸਮ ਦੀਆਂ ਟੇਬਲਾਂ ਦੇ ਸਮਾਨ ਹਨ, ਹਾਲਾਂਕਿ, ਡੇਟਾ ਵਾਲਟ ਵਿੱਚ ਸਰੋਗੇਟ ਵਜੋਂ ਕਾਰੋਬਾਰੀ ਕੁੰਜੀਆਂ ਦੇ ਇੱਕ ਸਮੂਹ ਤੋਂ ਹੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਪਹੁੰਚ ਸਰੋਤਾਂ ਤੋਂ ਸਬੰਧਾਂ ਅਤੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਲੋਡ ਕਰਨ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ (ਸਰੋਗੇਟ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਹੱਬ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ, ਸਿਰਫ਼ ਇੱਕ ਕੁਦਰਤੀ ਕੁੰਜੀ ਦੀ ਹੈਸ਼ ਦੀ ਗਣਨਾ ਕਰੋ), ਪਰ ਹੋਰ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ (ਉਦਾਹਰਣ ਵਜੋਂ, ਟੱਕਰਾਂ, ਕੇਸ ਅਤੇ ਗੈਰ-ਪ੍ਰਿੰਟ ਕਰਨ ਯੋਗ) ਸਟਰਿੰਗ ਕੁੰਜੀਆਂ ਵਿੱਚ ਅੱਖਰ, ਆਦਿ .p.), ਇਸਲਈ ਇਸਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਹੋਰ ਸਾਰੀਆਂ ਇਕਾਈ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿਸ਼ੇਸ਼ ਟੇਬਲਾਂ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਉਪਗ੍ਰਹਿ. ਇੱਕ ਹੱਬ ਵਿੱਚ ਗੁਣਾਂ ਦੇ ਵੱਖ-ਵੱਖ ਸੈੱਟਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਵਾਲੇ ਕਈ ਉਪਗ੍ਰਹਿ ਹੋ ਸਕਦੇ ਹਨ।

ਉਪਗ੍ਰਹਿ ਵਿੱਚ ਗੁਣਾਂ ਦੀ ਵੰਡ ਸਿਧਾਂਤ ਦੇ ਅਨੁਸਾਰ ਹੁੰਦੀ ਹੈ ਸੰਯੁਕਤ ਤਬਦੀਲੀ - ਇੱਕ ਸੈਟੇਲਾਈਟ ਵਿੱਚ ਗੈਰ-ਵਰਜਨ ਵਾਲੇ ਗੁਣਾਂ ਨੂੰ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਵਿਅਕਤੀ ਲਈ ਜਨਮ ਮਿਤੀ ਅਤੇ SNILS), ਦੂਜੇ ਵਿੱਚ - ਕਦੇ-ਕਦਾਈਂ ਬਦਲਦੇ ਸੰਸਕਰਣਾਂ (ਉਦਾਹਰਨ ਲਈ, ਆਖਰੀ ਨਾਮ ਅਤੇ ਪਾਸਪੋਰਟ ਨੰਬਰ), ਤੀਜੇ ਵਿੱਚ - ਅਕਸਰ ਬਦਲਦੇ ਹੋਏ। (ਉਦਾਹਰਨ ਲਈ, ਡਿਲੀਵਰੀ ਪਤਾ, ਸ਼੍ਰੇਣੀ, ਆਖਰੀ ਆਰਡਰ ਦੀ ਮਿਤੀ, ਆਦਿ)। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸੰਸਕਰਣ ਵਿਅਕਤੀਗਤ ਸੈਟੇਲਾਈਟ ਦੇ ਪੱਧਰ 'ਤੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਨਾ ਕਿ ਸਮੁੱਚੀ ਹਸਤੀ, ਇਸਲਈ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਵੰਡਣ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਜੋ ਇੱਕ ਸੈਟੇਲਾਈਟ ਦੇ ਅੰਦਰ ਸੰਸਕਰਣਾਂ ਦਾ ਇੰਟਰਸੈਕਸ਼ਨ ਘੱਟ ਹੋਵੇ (ਜੋ ਸਟੋਰ ਕੀਤੇ ਸੰਸਕਰਣਾਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ).

ਨਾਲ ਹੀ, ਡੇਟਾ ਲੋਡ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ, ਵੱਖ-ਵੱਖ ਸਰੋਤਾਂ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਅਕਸਰ ਵਿਅਕਤੀਗਤ ਉਪਗ੍ਰਹਿ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸੈਟੇਲਾਈਟ ਹੱਬ ਦੇ ਨਾਲ ਸੰਚਾਰ ਕਰਦੇ ਹਨ ਵਿਦੇਸ਼ੀ ਕੁੰਜੀ (ਜੋ ਕਿ 1-ਤੋਂ-ਕਈ ਕਾਰਡੀਨੈਲਿਟੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ)। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਮਲਟੀਪਲ ਐਟਰੀਬਿਊਟ ਮੁੱਲ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਕਲਾਇੰਟ ਲਈ ਮਲਟੀਪਲ ਸੰਪਰਕ ਫ਼ੋਨ ਨੰਬਰ) ਇਸ "ਡਿਫੌਲਟ" ਆਰਕੀਟੈਕਚਰ ਦੁਆਰਾ ਸਮਰਥਿਤ ਹਨ।

В ਐਂਕਰ ਮਾਡਲ ਕੁੰਜੀਆਂ ਸਟੋਰ ਕਰਨ ਵਾਲੀਆਂ ਟੇਬਲਾਂ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਐਂਕਰ. ਅਤੇ ਉਹ ਰੱਖਦੇ ਹਨ:

• ਸਿਰਫ਼ ਸਰੋਗੇਟ ਕੁੰਜੀਆਂ
• ਸਰੋਤ ਨਾਲ ਲਿੰਕ
• ਜੋੜਨ ਦਾ ਸਮਾਂ ਰਿਕਾਰਡ ਕਰੋ

ਐਂਕਰ ਮਾਡਲ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਕੁਦਰਤੀ ਕੁੰਜੀਆਂ ਨੂੰ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਆਮ ਗੁਣ. ਇਹ ਵਿਕਲਪ ਸਮਝਣਾ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਜਾਪਦਾ ਹੈ, ਪਰ ਇਹ ਵਸਤੂ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਜਾਇਸ਼ ਦਿੰਦਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਇੱਕੋ ਇਕਾਈ ਬਾਰੇ ਡੇਟਾ ਵੱਖ-ਵੱਖ ਪ੍ਰਣਾਲੀਆਂ ਤੋਂ ਆ ਸਕਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਆਪਣੀ ਕੁਦਰਤੀ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਡੇਟਾ ਵਾਲਟ ਵਿੱਚ, ਇਹ ਕਈ ਹੱਬਾਂ (ਇੱਕ ਪ੍ਰਤੀ ਸਰੋਤ + ਇੱਕ ਏਕੀਕ੍ਰਿਤ ਮਾਸਟਰ ਸੰਸਕਰਣ) ਦੀ ਬਜਾਏ ਬੋਝਲ ਬਣਤਰਾਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਐਂਕਰ ਮਾਡਲ ਵਿੱਚ, ਹਰੇਕ ਸਰੋਤ ਦੀ ਕੁਦਰਤੀ ਕੁੰਜੀ ਇਸਦੇ ਆਪਣੇ ਗੁਣ ਵਿੱਚ ਆਉਂਦੀ ਹੈ ਅਤੇ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਲੋਡ ਕਰਨ ਵੇਲੇ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਬਾਕੀ ਸਾਰੇ।

ਪਰ ਇੱਥੇ ਇੱਕ ਧੋਖਾਧੜੀ ਬਿੰਦੂ ਵੀ ਹੈ: ਜੇਕਰ ਵੱਖ-ਵੱਖ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਗੁਣਾਂ ਨੂੰ ਇੱਕ ਇਕਾਈ ਵਿੱਚ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਕੁਝ "ਗਲੂਇੰਗ" ਦੇ ਨਿਯਮ, ਜਿਸ ਦੁਆਰਾ ਸਿਸਟਮ ਨੂੰ ਇਹ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਵੱਖ-ਵੱਖ ਸਰੋਤਾਂ ਦੇ ਰਿਕਾਰਡ ਇਕਾਈ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ।

В ਡਾਟਾ ਵਾਲਟ ਇਹ ਨਿਯਮ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਗਠਨ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਗੇ ਮਾਸਟਰ ਇਕਾਈ ਦਾ "ਸਰੋਗੇਟ ਹੱਬ" ਅਤੇ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਉਹਨਾਂ ਹੱਬਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦੇ ਜੋ ਕੁਦਰਤੀ ਸਰੋਤ ਕੁੰਜੀਆਂ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਮੂਲ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਕਿਸੇ ਬਿੰਦੂ 'ਤੇ ਅਭੇਦ ਹੋਣ ਦੇ ਨਿਯਮ ਬਦਲ ਜਾਂਦੇ ਹਨ (ਜਾਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਿਨ੍ਹਾਂ ਦੁਆਰਾ ਇਹ ਪ੍ਰਦਰਸ਼ਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਨੂੰ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ), ਤਾਂ ਇਹ ਸਰੋਗੇਟ ਹੱਬ ਨੂੰ ਮੁੜ ਫਾਰਮੈਟ ਕਰਨ ਲਈ ਕਾਫੀ ਹੋਵੇਗਾ।

В ਐਂਕਰ ਮਾਡਲ ਅਜਿਹੀ ਇਕਾਈ ਨੂੰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇਗਾ ਸਿਰਫ਼ ਐਂਕਰ. ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਭਾਵੇਂ ਉਹ ਕਿਸੇ ਵੀ ਸਰੋਤ ਤੋਂ ਆਉਂਦੀਆਂ ਹੋਣ, ਇੱਕੋ ਸਰੋਗੇਟ ਨਾਲ ਜੁੜੀਆਂ ਹੋਣਗੀਆਂ। ਗਲਤੀ ਨਾਲ ਵਿਲੀਨ ਕੀਤੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਅਤੇ, ਆਮ ਤੌਰ 'ਤੇ, ਅਜਿਹੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਅਭੇਦ ਹੋਣ ਦੀ ਸਾਰਥਕਤਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜੇ ਨਿਯਮ ਕਾਫ਼ੀ ਗੁੰਝਲਦਾਰ ਹਨ ਅਤੇ ਅਕਸਰ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਇੱਕੋ ਵਿਸ਼ੇਸ਼ਤਾ ਵੱਖ-ਵੱਖ ਸਰੋਤਾਂ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ (ਹਾਲਾਂਕਿ ਇਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਸੰਭਵ ਹੈ, ਕਿਉਂਕਿ ਹਰੇਕ ਵਿਸ਼ੇਸ਼ਤਾ ਸੰਸਕਰਣ ਇਸਦੇ ਸਰੋਤ ਲਈ ਇੱਕ ਲਿੰਕ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ)।

ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ, ਜੇਕਰ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਡੁਪਲੀਕੇਸ਼ਨ, ਰਿਕਾਰਡਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਅਤੇ ਹੋਰ MDM ਤੱਤ, ਕੁਦਰਤੀ ਕੁੰਜੀਆਂ ਨੂੰ ਚੁਸਤ ਵਿਧੀਆਂ ਵਿੱਚ ਸਟੋਰ ਕਰਨ ਦੇ ਪਹਿਲੂਆਂ ਵੱਲ ਵਿਸ਼ੇਸ਼ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ। ਇਹ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਵੱਡਾ ਡਾਟਾ ਵਾਲਟ ਡਿਜ਼ਾਇਨ ਅਭੇਦ ਦੀਆਂ ਗਲਤੀਆਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਅਚਾਨਕ ਸੁਰੱਖਿਅਤ ਹੋ ਜਾਵੇਗਾ।

ਐਂਕਰ ਮਾਡਲ ਨਾਮਕ ਇੱਕ ਵਾਧੂ ਵਸਤੂ ਕਿਸਮ ਵੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਗੰਢ ਇਹ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਖਾਸ ਹੈ ਡੀਜਨਰੇਟ ਕਿਸਮ ਦੇ ਐਂਕਰ, ਜਿਸ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀ ਹੈ। ਨੋਡ ਫਲੈਟ ਡਾਇਰੈਕਟਰੀਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਲਿੰਗ, ਵਿਆਹੁਤਾ ਸਥਿਤੀ, ਗਾਹਕ ਸੇਵਾ ਸ਼੍ਰੇਣੀ, ਆਦਿ)। ਐਂਕਰ ਦੇ ਉਲਟ, ਗੰਢ ਕੋਈ ਸੰਬੰਧਿਤ ਵਿਸ਼ੇਸ਼ਤਾ ਸਾਰਣੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸਦਾ ਇੱਕੋ ਇੱਕ ਗੁਣ (ਨਾਮ) ਹਮੇਸ਼ਾ ਕੁੰਜੀ ਦੇ ਨਾਲ ਇੱਕੋ ਸਾਰਣੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਨੋਡਸ ਟਾਈ ਟੇਬਲ (ਟਾਈ) ਦੁਆਰਾ ਐਂਕਰਾਂ ਨਾਲ ਉਸੇ ਤਰ੍ਹਾਂ ਜੁੜੇ ਹੁੰਦੇ ਹਨ ਜਿਵੇਂ ਐਂਕਰ ਇੱਕ ਦੂਜੇ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ।

ਨੋਡਸ ਦੀ ਵਰਤੋਂ ਬਾਰੇ ਕੋਈ ਸਪੱਸ਼ਟ ਰਾਏ ਨਹੀਂ ਹੈ। ਉਦਾਹਰਣ ਲਈ, ਨਿਕੋਲੇ ਗੋਲੋਵ, ਜੋ ਰੂਸ ਵਿਚ ਐਂਕਰ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਨੂੰ ਸਰਗਰਮੀ ਨਾਲ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ, ਵਿਸ਼ਵਾਸ ਕਰਦਾ ਹੈ (ਗੈਰ ਤਰਕਹੀਣ ਨਹੀਂ) ਕਿ ਇਕ ਵੀ ਹਵਾਲਾ ਪੁਸਤਕ ਲਈ ਇਹ ਨਿਸ਼ਚਤਤਾ ਨਾਲ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਹਮੇਸ਼ਾ ਸਥਿਰ ਅਤੇ ਸਿੰਗਲ-ਪੱਧਰ ਦੀ ਹੋਵੇਗੀ, ਇਸਲਈ ਸਾਰੀਆਂ ਵਸਤੂਆਂ ਲਈ ਤੁਰੰਤ ਇੱਕ ਪੂਰੇ ਐਂਕਰ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ।

ਡੇਟਾ ਵਾਲਟ ਅਤੇ ਐਂਕਰ ਮਾਡਲ ਵਿਚਕਾਰ ਇੱਕ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ ਉਪਲਬਧਤਾ ਹੈ ਕੁਨੈਕਸ਼ਨ ਦੇ ਗੁਣ:

В ਡਾਟਾ ਵਾਲਟ ਲਿੰਕ ਹੱਬ ਵਰਗੀਆਂ ਪੂਰੀਆਂ ਵਸਤੂਆਂ ਹਨ, ਅਤੇ ਹੋ ਸਕਦੀਆਂ ਹਨ ਆਪਣੇ ਗੁਣ. The ਐਂਕਰ ਮਾਡਲ ਲਿੰਕਸ ਦੀ ਵਰਤੋਂ ਸਿਰਫ ਐਂਕਰਾਂ ਨੂੰ ਜੋੜਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਦੇ ਆਪਣੇ ਗੁਣ ਨਹੀਂ ਹੋ ਸਕਦੇ. ਇਸ ਅੰਤਰ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਮਾਡਲਿੰਗ ਪਹੁੰਚ ਹਨ ਤੱਥ, ਜਿਸ ਬਾਰੇ ਅੱਗੇ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ।

ਤੱਥ ਸਟੋਰੇਜ਼

ਇਸ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਮੁੱਖ ਤੌਰ 'ਤੇ ਮਾਪ ਮਾਡਲਿੰਗ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਸੀ. ਤੱਥ ਥੋੜੇ ਘੱਟ ਸਪੱਸ਼ਟ ਹਨ.

В ਡਾਟਾ ਵਾਲਟ ਤੱਥਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਇੱਕ ਖਾਸ ਵਸਤੂ ਹੈ ਲਿੰਕ, ਜਿਸ ਦੇ ਸੈਟੇਲਾਈਟਾਂ ਵਿੱਚ ਅਸਲ ਸੂਚਕਾਂ ਨੂੰ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ।

ਇਹ ਪਹੁੰਚ ਅਨੁਭਵੀ ਜਾਪਦੀ ਹੈ। ਇਹ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤੇ ਸੂਚਕਾਂ ਤੱਕ ਆਸਾਨ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਰਵਾਇਤੀ ਤੱਥ ਸਾਰਣੀ ਦੇ ਸਮਾਨ ਹੁੰਦਾ ਹੈ (ਸਿਰਫ਼ ਸੂਚਕਾਂ ਨੂੰ ਸਾਰਣੀ ਵਿੱਚ ਨਹੀਂ, ਸਗੋਂ "ਗੁਆਂਢੀ" ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ)। ਪਰ ਇੱਥੇ ਵੀ ਕਮੀਆਂ ਹਨ: ਮਾਡਲ ਦੀਆਂ ਆਮ ਸੋਧਾਂ ਵਿੱਚੋਂ ਇੱਕ - ਤੱਥ ਕੁੰਜੀ ਦਾ ਵਿਸਥਾਰ - ਜ਼ਰੂਰੀ ਹੈ ਲਿੰਕ ਵਿੱਚ ਇੱਕ ਨਵੀਂ ਵਿਦੇਸ਼ੀ ਕੁੰਜੀ ਜੋੜਨਾ. ਅਤੇ ਇਹ, ਬਦਲੇ ਵਿੱਚ, ਮਾਡਿਊਲਰਿਟੀ ਨੂੰ "ਤੋੜਦਾ ਹੈ" ਅਤੇ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਹੋਰ ਵਸਤੂਆਂ ਵਿੱਚ ਸੋਧਾਂ ਦੀ ਲੋੜ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ।

В ਐਂਕਰ ਮਾਡਲ ਇੱਕ ਕਨੈਕਸ਼ਨ ਦੇ ਆਪਣੇ ਗੁਣ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ, ਇਸਲਈ ਇਹ ਪਹੁੰਚ ਕੰਮ ਨਹੀਂ ਕਰੇਗੀ - ਬਿਲਕੁਲ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਸੂਚਕਾਂ ਨੂੰ ਇੱਕ ਖਾਸ ਐਂਕਰ ਨਾਲ ਲਿੰਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਤੋਂ ਸਿੱਟਾ ਸਰਲ ਹੈ- ਹਰੇਕ ਤੱਥ ਨੂੰ ਆਪਣੇ ਐਂਕਰ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ. ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਲਈ ਜੋ ਅਸੀਂ ਤੱਥਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਸਮਝਣ ਦੇ ਆਦੀ ਹਾਂ, ਇਹ ਕੁਦਰਤੀ ਲੱਗ ਸਕਦਾ ਹੈ - ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਖਰੀਦ ਦੇ ਤੱਥ ਨੂੰ "ਆਰਡਰ" ਜਾਂ "ਰਸੀਦ" ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਇੱਕ ਸੈਸ਼ਨ ਲਈ ਸਾਈਟ 'ਤੇ ਜਾਣਾ, ਆਦਿ। ਪਰ ਅਜਿਹੇ ਤੱਥ ਵੀ ਹਨ ਜਿਨ੍ਹਾਂ ਲਈ ਅਜਿਹੇ ਕੁਦਰਤੀ "ਕੈਰੀਅਰ ਆਬਜੈਕਟ" ਨੂੰ ਲੱਭਣਾ ਇੰਨਾ ਆਸਾਨ ਨਹੀਂ ਹੈ - ਉਦਾਹਰਨ ਲਈ, ਹਰ ਦਿਨ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਗੁਦਾਮਾਂ ਵਿੱਚ ਮਾਲ ਦੇ ਬਚੇ ਹੋਏ.

ਇਸ ਅਨੁਸਾਰ, ਐਂਕਰ ਮਾਡਲ ਵਿੱਚ ਤੱਥ ਕੁੰਜੀ ਦਾ ਵਿਸਤਾਰ ਕਰਦੇ ਸਮੇਂ ਮਾਡਿਊਲਰਿਟੀ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਨਹੀਂ ਹੁੰਦੀਆਂ (ਇਹ ਸਿਰਫ਼ ਸੰਬੰਧਿਤ ਐਂਕਰ ਨਾਲ ਇੱਕ ਨਵਾਂ ਰਿਸ਼ਤਾ ਜੋੜਨਾ ਕਾਫੀ ਹੈ), ਪਰ ਤੱਥਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ ਇੱਕ ਮਾਡਲ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਘੱਟ ਅਸਪਸ਼ਟ ਹੈ; "ਨਕਲੀ" ਐਂਕਰ ਦਿਖਾਈ ਦੇ ਸਕਦੇ ਹਨ। ਜੋ ਕਾਰੋਬਾਰੀ ਵਸਤੂ ਮਾਡਲ ਨੂੰ ਅਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੇ ਹਨ।

ਲਚਕਤਾ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ

ਦੋਨੋ ਮਾਮਲੇ ਵਿੱਚ ਨਤੀਜੇ ਉਸਾਰੀ ਸ਼ਾਮਿਲ ਹਨ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਹੋਰ ਟੇਬਲਰਵਾਇਤੀ ਮਾਪ ਨਾਲੋਂ. ਪਰ ਇਸ ਨੂੰ ਲੱਗ ਸਕਦਾ ਹੈ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘੱਟ ਡਿਸਕ ਸਪੇਸ ਪਰੰਪਰਾਗਤ ਆਯਾਮ ਦੇ ਰੂਪ ਵਿੱਚ ਵਰਜਨਡ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਸਮਾਨ ਸੈੱਟ ਦੇ ਨਾਲ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਇੱਥੇ ਕੋਈ ਜਾਦੂ ਨਹੀਂ ਹੈ - ਇਹ ਸਭ ਆਮ ਕਰਨ ਬਾਰੇ ਹੈ. ਸੈਟੇਲਾਈਟਾਂ (ਡੇਟਾ ਵਾਲਟ ਵਿੱਚ) ਜਾਂ ਵਿਅਕਤੀਗਤ ਟੇਬਲਾਂ (ਐਂਕਰ ਮਾਡਲ) ਵਿੱਚ ਗੁਣਾਂ ਨੂੰ ਵੰਡ ਕੇ, ਅਸੀਂ ਘਟਾਉਂਦੇ ਹਾਂ (ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ) ਦੂਜਿਆਂ ਨੂੰ ਬਦਲਣ ਵੇਲੇ ਕੁਝ ਗੁਣਾਂ ਦੇ ਮੁੱਲਾਂ ਦੀ ਨਕਲ.

ਕਰਨ ਲਈ ਡਾਟਾ ਵਾਲਟ ਜਿੱਤਾਂ ਸੈਟੇਲਾਈਟਾਂ ਵਿਚਕਾਰ ਗੁਣਾਂ ਦੀ ਵੰਡ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਲਈ ਐਂਕਰ ਮਾਡਲ — ਪ੍ਰਤੀ ਮਾਪ ਵਸਤੂ ਦੇ ਸੰਸਕਰਣਾਂ ਦੀ ਔਸਤ ਸੰਖਿਆ ਦੇ ਲਗਭਗ ਸਿੱਧੇ ਅਨੁਪਾਤਕ ਹੈ।

ਹਾਲਾਂਕਿ, ਸਪੇਸ ਸੇਵਿੰਗ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਪਰ ਮੁੱਖ ਨਹੀਂ, ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕਰਨ ਦਾ ਫਾਇਦਾ ਹੈ। ਰਿਸ਼ਤਿਆਂ ਦੀ ਵੱਖਰੀ ਸਟੋਰੇਜ ਦੇ ਨਾਲ, ਇਹ ਪਹੁੰਚ ਸਟੋਰ ਬਣਾਉਂਦਾ ਹੈ ਮਾਡਯੂਲਰ ਡਿਜ਼ਾਈਨ. ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਜਿਹੇ ਮਾਡਲ ਵਿੱਚ ਵਿਅਕਤੀਗਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਪੂਰੇ ਨਵੇਂ ਵਿਸ਼ਾ ਖੇਤਰਾਂ ਨੂੰ ਜੋੜਨਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਉੱਚ ਢਾਂਚਾ ਵਸਤੂਆਂ ਦੇ ਮੌਜੂਦਾ ਸੈੱਟ ਉੱਤੇ ਉਹਨਾਂ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ। ਅਤੇ ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ ਵਰਣਿਤ ਵਿਧੀਆਂ ਨੂੰ ਲਚਕਦਾਰ ਬਣਾਉਂਦਾ ਹੈ।

ਇਹ ਟੁਕੜੇ ਦੇ ਉਤਪਾਦਨ ਤੋਂ ਵੱਡੇ ਉਤਪਾਦਨ ਵਿੱਚ ਤਬਦੀਲੀ ਨਾਲ ਵੀ ਮੇਲ ਖਾਂਦਾ ਹੈ - ਜੇ ਰਵਾਇਤੀ ਪਹੁੰਚ ਵਿੱਚ ਮਾਡਲ ਦੀ ਹਰੇਕ ਸਾਰਣੀ ਵਿਲੱਖਣ ਹੈ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਧਿਆਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਲਚਕਦਾਰ ਵਿਧੀਆਂ ਵਿੱਚ ਇਹ ਪਹਿਲਾਂ ਹੀ ਮਿਆਰੀ "ਪੁਰਜ਼ਿਆਂ" ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ। ਇੱਕ ਪਾਸੇ, ਹੋਰ ਟੇਬਲ ਹਨ, ਅਤੇ ਡੇਟਾ ਨੂੰ ਲੋਡ ਕਰਨ ਅਤੇ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਦਿਖਾਈ ਦੇਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ. ਦੂਜੇ ਪਾਸੇ, ਉਹ ਬਣ ਜਾਂਦੇ ਹਨ ਆਮ. ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹੋ ਸਕਦਾ ਹੈ ਸਵੈਚਲਿਤ ਅਤੇ ਮੈਟਾਡੇਟਾ ਸੰਚਾਲਿਤ. ਸਵਾਲ "ਅਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਰੱਖਾਂਗੇ?", ਜਿਸਦਾ ਜਵਾਬ ਡਿਜ਼ਾਇਨਿੰਗ ਸੁਧਾਰਾਂ 'ਤੇ ਕੰਮ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਲੈ ਸਕਦਾ ਹੈ, ਹੁਣ ਇਸਦੀ ਕੀਮਤ ਨਹੀਂ ਹੈ (ਨਾਲ ਹੀ ਕੰਮ ਕਰਨ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ 'ਤੇ ਮਾਡਲ ਨੂੰ ਬਦਲਣ ਦੇ ਪ੍ਰਭਾਵ ਬਾਰੇ ਸਵਾਲ) ).

ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਅਜਿਹੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਵਿਸ਼ਲੇਸ਼ਕਾਂ ਦੀ ਬਿਲਕੁਲ ਲੋੜ ਨਹੀਂ ਹੈ - ਕਿਸੇ ਨੂੰ ਅਜੇ ਵੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਾਲੇ ਆਬਜੈਕਟ ਦੇ ਸਮੂਹ ਦੁਆਰਾ ਕੰਮ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਅਤੇ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਇਹ ਸਭ ਕਿੱਥੇ ਅਤੇ ਕਿਵੇਂ ਲੋਡ ਕਰਨਾ ਹੈ. ਪਰ ਕੰਮ ਦੀ ਮਾਤਰਾ, ਅਤੇ ਨਾਲ ਹੀ ਇੱਕ ਗਲਤੀ ਦੀ ਸੰਭਾਵਨਾ ਅਤੇ ਲਾਗਤ, ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘੱਟ ਜਾਂਦੀ ਹੈ. ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਪੜਾਅ 'ਤੇ ਅਤੇ ETL ਦੇ ਵਿਕਾਸ ਦੇ ਦੌਰਾਨ, ਜੋ ਕਿ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸੇ ਵਿੱਚ ਮੈਟਾਡੇਟਾ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਲਈ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ.

ਹਨੇਰਾ ਪਾਸਾ

ਉਪਰੋਕਤ ਸਾਰੇ ਦੋਵੇਂ ਪਹੁੰਚਾਂ ਨੂੰ ਸੱਚਮੁੱਚ ਲਚਕਦਾਰ, ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਉੱਨਤ ਅਤੇ ਦੁਹਰਾਓ ਸੁਧਾਰ ਲਈ ਢੁਕਵਾਂ ਬਣਾਉਂਦੇ ਹਨ। ਬੇਸ਼ੱਕ, ਇੱਥੇ ਇੱਕ "ਅਤਰ ਵਿੱਚ ਬੈਰਲ" ਵੀ ਹੈ, ਜਿਸ ਬਾਰੇ ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹੋ.

ਡੇਟਾ ਸੜਨ, ਜੋ ਲਚਕਦਾਰ ਆਰਕੀਟੈਕਚਰ ਦੀ ਮਾਡਯੂਲਰਿਟੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਟੇਬਲਾਂ ਦੀ ਗਿਣਤੀ ਵਿੱਚ ਵਾਧਾ ਕਰਦਾ ਹੈ ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਓਵਰਹੈੱਡ ਨਮੂਨਾ ਲੈਣ ਵੇਲੇ ਸ਼ਾਮਲ ਹੋਣ ਲਈ। ਇੱਕ ਮਾਪ ਦੇ ਸਾਰੇ ਗੁਣਾਂ ਨੂੰ ਸਿਰਫ਼ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਇੱਕ ਕਲਾਸਿਕ ਸਟੋਰ ਵਿੱਚ ਇੱਕ ਚੋਣ ਕਾਫ਼ੀ ਹੈ, ਪਰ ਇੱਕ ਲਚਕਦਾਰ ਆਰਕੀਟੈਕਚਰ ਲਈ ਜੋੜਾਂ ਦੀ ਇੱਕ ਪੂਰੀ ਲੜੀ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇਕਰ ਰਿਪੋਰਟਾਂ ਲਈ ਇਹ ਸਾਰੀਆਂ ਜੋੜਾਂ ਪਹਿਲਾਂ ਤੋਂ ਲਿਖੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਤਾਂ ਵਿਸ਼ਲੇਸ਼ਕ ਜੋ ਹੱਥ ਨਾਲ SQL ਲਿਖਣ ਦੇ ਆਦੀ ਹਨ, ਨੂੰ ਦੁੱਗਣਾ ਨੁਕਸਾਨ ਹੋਵੇਗਾ.

ਇੱਥੇ ਕਈ ਤੱਥ ਹਨ ਜੋ ਇਸ ਸਥਿਤੀ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ:

ਵੱਡੇ ਮਾਪਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਇਸਦੇ ਸਾਰੇ ਗੁਣ ਲਗਭਗ ਕਦੇ ਵੀ ਇੱਕੋ ਸਮੇਂ ਵਰਤੇ ਨਹੀਂ ਜਾਂਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਮਾਡਲ 'ਤੇ ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ ਜਾਪਦੇ ਨਾਲੋਂ ਘੱਟ ਜੋੜ ਹੋ ਸਕਦੇ ਹਨ। ਡਾਟਾ ਵਾਲਟ ਸੈਟੇਲਾਈਟਾਂ ਨੂੰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਿਰਧਾਰਤ ਕਰਨ ਵੇਲੇ ਸ਼ੇਅਰਿੰਗ ਦੀ ਸੰਭਾਵਿਤ ਬਾਰੰਬਾਰਤਾ ਨੂੰ ਵੀ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਸਕਦਾ ਹੈ। ਇਸਦੇ ਨਾਲ ਹੀ, ਲੋਡਿੰਗ ਪੜਾਅ 'ਤੇ ਸਰੋਗੇਟਸ ਬਣਾਉਣ ਅਤੇ ਮੈਪ ਕਰਨ ਲਈ ਮੁੱਖ ਤੌਰ 'ਤੇ ਹੱਬ ਜਾਂ ਐਂਕਰਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਸਵਾਲਾਂ ਵਿੱਚ ਘੱਟ ਹੀ ਵਰਤੇ ਜਾਂਦੇ ਹਨ (ਇਹ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਐਂਕਰਾਂ ਲਈ ਸੱਚ ਹੈ)।

ਸਾਰੇ ਜੋੜ ਕੁੰਜੀ ਦੁਆਰਾ ਹੁੰਦੇ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦਾ ਇੱਕ ਹੋਰ "ਸੰਕੁਚਿਤ" ਤਰੀਕਾ ਸਕੈਨਿੰਗ ਟੇਬਲ ਦੇ ਓਵਰਹੈੱਡ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਇਸਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਵਿਸ਼ੇਸ਼ਤਾ ਮੁੱਲ ਦੁਆਰਾ ਫਿਲਟਰ ਕਰਨ ਵੇਲੇ)। ਇਹ ਇਸ ਤੱਥ ਦੀ ਅਗਵਾਈ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਜੋੜਾਂ ਦੇ ਝੁੰਡ ਦੇ ਨਾਲ ਇੱਕ ਸਧਾਰਨ ਡੇਟਾਬੇਸ ਤੋਂ ਨਮੂਨਾ ਲੈਣਾ ਪ੍ਰਤੀ ਕਤਾਰ ਦੇ ਕਈ ਸੰਸਕਰਣਾਂ ਦੇ ਨਾਲ ਇੱਕ ਭਾਰੀ ਮਾਪ ਨੂੰ ਸਕੈਨ ਕਰਨ ਨਾਲੋਂ ਵੀ ਤੇਜ਼ ਹੋਵੇਗਾ।

ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ ਵਿੱਚ ਇਹ ਲੇਖ ਵਿੱਚ ਇੱਕ ਸਾਰਣੀ ਤੋਂ ਨਮੂਨੇ ਦੇ ਨਾਲ ਐਂਕਰ ਮਾਡਲ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਤੁਲਨਾਤਮਕ ਟੈਸਟ ਸ਼ਾਮਲ ਹੈ।

ਬਹੁਤ ਕੁਝ ਇੰਜਣ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ. ਬਹੁਤ ਸਾਰੇ ਆਧੁਨਿਕ ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚ ਅੰਦਰੂਨੀ ਜੋੜਨ ਦੀ ਅਨੁਕੂਲਤਾ ਵਿਧੀ ਹੁੰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, MS SQL ਅਤੇ Oracle ਟੇਬਲਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਨੂੰ "ਛੱਡ" ਸਕਦੇ ਹਨ ਜੇਕਰ ਉਹਨਾਂ ਦਾ ਡੇਟਾ ਹੋਰ ਜੋੜਾਂ ਨੂੰ ਛੱਡ ਕੇ ਕਿਤੇ ਵੀ ਨਹੀਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅੰਤਿਮ ਚੋਣ (ਸਾਰਣੀ/ਜੋੜਨ ਦੇ ਖਾਤਮੇ), ਅਤੇ MPP ਵਰਟੀਕਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਅਵੀਟੋ ਤੋਂ ਸਾਥੀਆਂ ਦਾ ਤਜਰਬਾ, ਐਂਕਰ ਮਾਡਲ ਲਈ ਇੱਕ ਸ਼ਾਨਦਾਰ ਇੰਜਣ ਸਾਬਤ ਹੋਇਆ ਹੈ, ਕਿਊਰੀ ਪਲਾਨ ਦੇ ਕੁਝ ਮੈਨੂਅਲ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਦਿੱਤੇ ਗਏ ਹਨ। ਦੂਜੇ ਪਾਸੇ, ਐਂਕਰ ਮਾਡਲ ਨੂੰ ਸਟੋਰ ਕਰਨਾ, ਉਦਾਹਰਨ ਲਈ, ਕਲਿਕ ਹਾਊਸ 'ਤੇ, ਜਿਸ ਵਿੱਚ ਸੀਮਤ ਜੁਆਇਨ ਸਮਰਥਨ ਹੈ, ਅਜੇ ਤੱਕ ਇੱਕ ਬਹੁਤ ਵਧੀਆ ਵਿਚਾਰ ਨਹੀਂ ਜਾਪਦਾ ਹੈ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਦੋਵੇਂ ਆਰਕੀਟੈਕਚਰ ਲਈ ਹਨ ਵਿਸ਼ੇਸ਼ ਚਾਲ, ਡਾਟਾ ਐਕਸੈਸ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣਾ (ਦੋਵੇਂ ਇੱਕ ਪੁੱਛਗਿੱਛ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਅਤੇ ਅੰਤਮ ਉਪਭੋਗਤਾਵਾਂ ਲਈ)। ਉਦਾਹਰਣ ਲਈ, ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਟੇਬਲ ਡਾਟਾ ਵਾਲਟ ਵਿੱਚ ਜਾਂ ਵਿਸ਼ੇਸ਼ ਟੇਬਲ ਫੰਕਸ਼ਨ ਐਂਕਰ ਮਾਡਲ ਵਿੱਚ.

ਕੁੱਲ

ਵਿਚਾਰੇ ਗਏ ਲਚਕਦਾਰ ਆਰਕੀਟੈਕਚਰ ਦਾ ਮੁੱਖ ਤੱਤ ਉਹਨਾਂ ਦੇ "ਡਿਜ਼ਾਈਨ" ਦੀ ਮਾਡਿਊਲਰਿਟੀ ਹੈ।

ਇਹ ਇਹ ਸੰਪਤੀ ਹੈ ਜੋ ਆਗਿਆ ਦਿੰਦੀ ਹੈ:

• ਮੈਟਾਡੇਟਾ ਤੈਨਾਤੀ ਅਤੇ ਮੂਲ ETL ਐਲਗੋਰਿਦਮ ਲਿਖਣ ਨਾਲ ਸੰਬੰਧਿਤ ਕੁਝ ਸ਼ੁਰੂਆਤੀ ਤਿਆਰੀ ਤੋਂ ਬਾਅਦ, ਗਾਹਕ ਨੂੰ ਤੁਰੰਤ ਪਹਿਲਾ ਨਤੀਜਾ ਪ੍ਰਦਾਨ ਕਰੋ ਕੁਝ ਰਿਪੋਰਟਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਜਿਸ ਵਿੱਚ ਕੁਝ ਸਰੋਤ ਵਸਤੂਆਂ ਤੋਂ ਡੇਟਾ ਸ਼ਾਮਲ ਹੈ। ਇਹ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ ਕਿ ਪੂਰੇ ਆਬਜੈਕਟ ਮਾਡਲ ਨੂੰ (ਉੱਤੇ ਪੱਧਰ 'ਤੇ ਵੀ) ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਸੋਚਿਆ ਜਾਵੇ।
• ਇੱਕ ਡੇਟਾ ਮਾਡਲ ਸਿਰਫ 2-3 ਵਸਤੂਆਂ ਨਾਲ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ (ਅਤੇ ਉਪਯੋਗੀ ਹੋ ਸਕਦਾ ਹੈ), ਅਤੇ ਫਿਰ ਹੌਲੀ ਹੌਲੀ ਵਧਣਾ (ਐਂਕਰ ਮਾਡਲ ਨਿਕੋਲਾਈ ਬਾਰੇ ਲਾਗੂ ਕੀਤਾ ਮਾਈਸੀਲੀਅਮ ਨਾਲ ਚੰਗੀ ਤੁਲਨਾ)।
• ਜ਼ਿਆਦਾਤਰ ਸੁਧਾਰ, ਵਿਸ਼ੇ ਖੇਤਰ ਨੂੰ ਵਧਾਉਣਾ ਅਤੇ ਨਵੇਂ ਸਰੋਤਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਮੌਜੂਦਾ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਤੋੜਨ ਦਾ ਖਤਰਾ ਨਹੀਂ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ.
• ਮਿਆਰੀ ਤੱਤਾਂ ਵਿੱਚ ਸੜਨ ਲਈ ਧੰਨਵਾਦ, ਅਜਿਹੀਆਂ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ETL ਪ੍ਰਕਿਰਿਆਵਾਂ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਦੀ ਲਿਖਤ ਆਪਣੇ ਆਪ ਨੂੰ ਐਲਗੋਰਿਦਮਾਈਜ਼ੇਸ਼ਨ ਵੱਲ ਉਧਾਰ ਦਿੰਦੀ ਹੈ ਅਤੇ ਅੰਤ ਵਿੱਚ, ਆਟੋਮੇਸ਼ਨ.

ਇਸ ਲਚਕਤਾ ਦੀ ਕੀਮਤ ਹੈ ਪ੍ਰਦਰਸ਼ਨ. ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਅਜਿਹੇ ਮਾਡਲਾਂ 'ਤੇ ਸਵੀਕਾਰਯੋਗ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਅਸੰਭਵ ਹੈ. ਜ਼ਿਆਦਾ ਵਾਰ ਨਹੀਂ, ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੇ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਵੇਰਵੇ ਵੱਲ ਵਧੇਰੇ ਜਤਨ ਅਤੇ ਧਿਆਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।

ਐਪਸ

ਇਕਾਈ ਦੀਆਂ ਕਿਸਮਾਂ ਡਾਟਾ ਵਾਲਟ

Data Vault ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ:
ਡੈਨ ਲਿਸਟੈਡ ਦੀ ਵੈੱਬਸਾਈਟ
ਰੂਸੀ ਵਿੱਚ ਡਾਟਾ ਵਾਲਟ ਬਾਰੇ ਸਭ
ਹੈਬਰੇ 'ਤੇ ਡਾਟਾ ਵਾਲਟ ਬਾਰੇ

ਇਕਾਈ ਦੀਆਂ ਕਿਸਮਾਂ ਐਂਕਰ ਮਾਡਲ

ਐਂਕਰ ਮਾਡਲ ਬਾਰੇ ਹੋਰ ਵੇਰਵੇ:

ਐਂਕਰ ਮਾਡਲ ਦੇ ਨਿਰਮਾਤਾਵਾਂ ਦੀ ਵੈੱਬਸਾਈਟ
ਅਵੀਟੋ ਵਿੱਚ ਐਂਕਰ ਮਾਡਲ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਅਨੁਭਵ ਬਾਰੇ ਲੇਖ

ਆਮ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਵਿਚਾਰੇ ਗਏ ਪਹੁੰਚਾਂ ਦੇ ਅੰਤਰਾਂ ਵਾਲੀ ਸੰਖੇਪ ਸਾਰਣੀ:

ਸਰੋਤ: www.habr.com