ಶೇಖರಣಾ ಸೌಲಭ್ಯವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು ದೀರ್ಘ ಮತ್ತು ಗಂಭೀರವಾದ ಕಾರ್ಯವಾಗಿದೆ.
ಪ್ರಾಜೆಕ್ಟ್‌ನ ಜೀವನದಲ್ಲಿ ಹೆಚ್ಚಿನವು ಆಬ್ಜೆಕ್ಟ್ ಮಾದರಿ ಮತ್ತು ಮೂಲ ರಚನೆಯು ಪ್ರಾರಂಭದಲ್ಲಿ ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಯೋಚಿಸಲ್ಪಟ್ಟಿದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.
ಸಾಮಾನ್ಯವಾಗಿ ಅಂಗೀಕರಿಸಲ್ಪಟ್ಟ ವಿಧಾನವು ಸ್ಟಾರ್ ಸ್ಕೀಮ್ ಅನ್ನು ಮೂರನೇ ಸಾಮಾನ್ಯ ರೂಪದೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ ವಿವಿಧ ರೂಪಾಂತರಗಳಾಗಿವೆ ಮತ್ತು ಉಳಿದಿದೆ. ನಿಯಮದಂತೆ, ತತ್ವದ ಪ್ರಕಾರ: ಆರಂಭಿಕ ಡೇಟಾ - 3NF, ಪ್ರದರ್ಶನಗಳು - ನಕ್ಷತ್ರ. ಈ ವಿಧಾನವು ಸಮಯ-ಪರೀಕ್ಷಿತ ಮತ್ತು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಸಂಶೋಧನೆಯಿಂದ ಬೆಂಬಲಿತವಾಗಿದೆ, ಇದು ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಭಂಡಾರ ಹೇಗಿರಬೇಕು ಎಂಬುದರ ಕುರಿತು ಯೋಚಿಸುವಾಗ ಅನುಭವಿ DWH ತಜ್ಞರ ಮನಸ್ಸಿಗೆ ಬರುವ ಮೊದಲ (ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಏಕೈಕ) ವಿಷಯವಾಗಿದೆ.
ಮತ್ತೊಂದೆಡೆ, ಸಾಮಾನ್ಯವಾಗಿ ವ್ಯಾಪಾರ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ಗ್ರಾಹಕರ ಅಗತ್ಯತೆಗಳು ತ್ವರಿತವಾಗಿ ಬದಲಾಗುತ್ತವೆ ಮತ್ತು ಡೇಟಾವು "ಆಳ" ಮತ್ತು "ಅಗಲ" ಎರಡರಲ್ಲೂ ಬೆಳೆಯುತ್ತದೆ. ಮತ್ತು ಇಲ್ಲಿ ನಕ್ಷತ್ರದ ಮುಖ್ಯ ಅನಾನುಕೂಲತೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ - ಸೀಮಿತವಾಗಿದೆ ನಮ್ಯತೆ.
DWH ಡೆವಲಪರ್ ಆಗಿ ನಿಮ್ಮ ಶಾಂತ ಮತ್ತು ಸ್ನೇಹಶೀಲ ಜೀವನದಲ್ಲಿ ಇದ್ದಕ್ಕಿದ್ದಂತೆ:
- ಕಾರ್ಯವು ಹುಟ್ಟಿಕೊಂಡಿತು "ಕನಿಷ್ಠ ಏನನ್ನಾದರೂ ತ್ವರಿತವಾಗಿ ಮಾಡಲು, ಮತ್ತು ನಂತರ ನಾವು ನೋಡುತ್ತೇವೆ";
- ಹೊಸ ಮೂಲಗಳ ಸಂಪರ್ಕ ಮತ್ತು ವಾರಕ್ಕೊಮ್ಮೆಯಾದರೂ ವ್ಯಾಪಾರ ಮಾದರಿಯ ಮರುಕೆಲಸದೊಂದಿಗೆ ವೇಗವಾಗಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿರುವ ಯೋಜನೆಯು ಕಾಣಿಸಿಕೊಂಡಿತು;
- ಸಿಸ್ಟಮ್ ಹೇಗಿರಬೇಕು ಮತ್ತು ಅದು ಅಂತಿಮವಾಗಿ ಯಾವ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕು ಎಂದು ತಿಳಿದಿಲ್ಲದ ಗ್ರಾಹಕರು ಕಾಣಿಸಿಕೊಂಡಿದ್ದಾರೆ, ಆದರೆ ಸತತವಾಗಿ ಹತ್ತಿರವಾಗುತ್ತಿರುವಾಗ ಬಯಸಿದ ಫಲಿತಾಂಶವನ್ನು ಪ್ರಯೋಗಿಸಲು ಮತ್ತು ಸ್ಥಿರವಾಗಿ ಪರಿಷ್ಕರಿಸಲು ಸಿದ್ಧರಾಗಿದ್ದಾರೆ;
- ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜರ್ ಒಳ್ಳೆಯ ಸುದ್ದಿಯೊಂದಿಗೆ ಕೈಬಿಟ್ಟರು: "ಮತ್ತು ಈಗ ನಾವು ಚುರುಕುತನವನ್ನು ಹೊಂದಿದ್ದೇವೆ!"
ಅಥವಾ ನೀವು ಶೇಖರಣಾ ಸೌಲಭ್ಯಗಳನ್ನು ಬೇರೆ ಹೇಗೆ ನಿರ್ಮಿಸಬಹುದು ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ನೀವು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ - ಕಟ್‌ಗೆ ಸ್ವಾಗತ!
"ನಮ್ಯತೆ" ಎಂದರೆ ಏನು?
ಮೊದಲಿಗೆ, "ಹೊಂದಿಕೊಳ್ಳುವ" ಎಂದು ಕರೆಯಲು ಸಿಸ್ಟಮ್ ಯಾವ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿರಬೇಕು ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸೋಣ.
ಪ್ರತ್ಯೇಕವಾಗಿ, ವಿವರಿಸಿದ ಗುಣಲಕ್ಷಣಗಳು ನಿರ್ದಿಷ್ಟವಾಗಿ ಸಂಬಂಧಿಸಿರಬೇಕು ಎಂದು ನಮೂದಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ ವ್ಯವಸ್ಥೆ, ಅಲ್ಲ ಪ್ರಕ್ರಿಯೆ ಅದರ ಅಭಿವೃದ್ಧಿ. ಆದ್ದರಿಂದ, ನೀವು ಅಗೈಲ್ ಬಗ್ಗೆ ಅಭಿವೃದ್ಧಿ ವಿಧಾನವಾಗಿ ಓದಲು ಬಯಸಿದರೆ, ಇತರ ಲೇಖನಗಳನ್ನು ಓದುವುದು ಉತ್ತಮ. ಉದಾಹರಣೆಗೆ, ಅಲ್ಲಿಯೇ, ಹಬ್ರೆಯಲ್ಲಿ, ಬಹಳಷ್ಟು ಆಸಕ್ತಿದಾಯಕ ವಸ್ತುಗಳಿವೆ (ಉದಾಹರಣೆಗೆ и , ಮತ್ತು ).
ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಡೇಟಾ ಗೋದಾಮಿನ ರಚನೆಯು ಸಂಪೂರ್ಣವಾಗಿ ಸಂಬಂಧವಿಲ್ಲ ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ. ಒಟ್ಟಾರೆಯಾಗಿ, ಅಗೈಲ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಾಗಿ ಅಗೈಲ್ ರೆಪೊಸಿಟರಿಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು ಗಮನಾರ್ಹವಾಗಿ ಸುಲಭವಾಗಿರುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಕಿಂಬಾಲ್ ಮತ್ತು ಡಾಟಾವಾಲ್ಟ್ ಪ್ರಕಾರ ಕ್ಲಾಸಿಕ್ ಡಿಡಬ್ಲ್ಯೂಹೆಚ್‌ನ ಚುರುಕುಬುದ್ಧಿಯ ಅಭಿವೃದ್ಧಿಯೊಂದಿಗೆ ಹೆಚ್ಚಾಗಿ ಆಯ್ಕೆಗಳಿವೆ - ಜಲಪಾತದ ಪ್ರಕಾರ, ಒಂದು ಯೋಜನೆಯಲ್ಲಿ ಅದರ ಎರಡು ರೂಪಗಳಲ್ಲಿ ನಮ್ಯತೆಯ ಸಂತೋಷದ ಕಾಕತಾಳೀಯತೆಗಳಿಗಿಂತ.
ಆದ್ದರಿಂದ, ಹೊಂದಿಕೊಳ್ಳುವ ಸಂಗ್ರಹಣೆಯು ಯಾವ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿರಬೇಕು? ಇಲ್ಲಿ ಮೂರು ಅಂಶಗಳಿವೆ:
- ಆರಂಭಿಕ ವಿತರಣೆ ಮತ್ತು ವೇಗದ ತಿರುವು - ಇದರರ್ಥ ಆದರ್ಶಪ್ರಾಯವಾಗಿ ಮೊದಲ ವ್ಯವಹಾರ ಫಲಿತಾಂಶವನ್ನು (ಉದಾಹರಣೆಗೆ, ಮೊದಲ ಕೆಲಸದ ವರದಿಗಳು) ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಪಡೆಯಬೇಕು, ಅಂದರೆ, ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸುವ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು. ಇದಲ್ಲದೆ, ಪ್ರತಿ ನಂತರದ ಪರಿಷ್ಕರಣೆಯು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು.
- ಪುನರಾವರ್ತಿತ ಪರಿಷ್ಕರಣೆ - ಇದರರ್ಥ ಪ್ರತಿ ನಂತರದ ಸುಧಾರಣೆಯು ಈಗಾಗಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಕಾರ್ಯವನ್ನು ಆದರ್ಶವಾಗಿ ಪರಿಣಾಮ ಬೀರಬಾರದು. ಈ ಕ್ಷಣವೇ ದೊಡ್ಡ ಯೋಜನೆಗಳಲ್ಲಿ ದೊಡ್ಡ ದುಃಸ್ವಪ್ನವಾಗುತ್ತದೆ - ಬೇಗ ಅಥವಾ ನಂತರ, ವೈಯಕ್ತಿಕ ವಸ್ತುಗಳು ಹಲವಾರು ಸಂಪರ್ಕಗಳನ್ನು ಪಡೆಯಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೋಷ್ಟಕಕ್ಕೆ ಕ್ಷೇತ್ರವನ್ನು ಸೇರಿಸುವುದಕ್ಕಿಂತ ಹತ್ತಿರದ ನಕಲಿನಲ್ಲಿ ತರ್ಕವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪುನರಾವರ್ತಿಸುವುದು ಸುಲಭವಾಗುತ್ತದೆ. ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವಸ್ತುಗಳ ಮೇಲೆ ಸುಧಾರಣೆಗಳ ಪ್ರಭಾವವನ್ನು ವಿಶ್ಲೇಷಿಸುವುದು ಸುಧಾರಣೆಗಳಿಗಿಂತ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಎಂದು ನೀವು ಆಶ್ಚರ್ಯಪಟ್ಟರೆ, ನೀವು ಬ್ಯಾಂಕಿಂಗ್ ಅಥವಾ ಟೆಲಿಕಾಂನಲ್ಲಿ ದೊಡ್ಡ ಡೇಟಾ ಗೋದಾಮುಗಳೊಂದಿಗೆ ಇನ್ನೂ ಕೆಲಸ ಮಾಡಿಲ್ಲ.
- ಬದಲಾಗುತ್ತಿರುವ ವ್ಯಾಪಾರ ಅಗತ್ಯಗಳಿಗೆ ನಿರಂತರವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುವುದು - ಒಟ್ಟಾರೆ ವಸ್ತುವಿನ ರಚನೆಯನ್ನು ಸಂಭವನೀಯ ವಿಸ್ತರಣೆಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳದೆ ವಿನ್ಯಾಸಗೊಳಿಸಬೇಕು, ಆದರೆ ಈ ಮುಂದಿನ ವಿಸ್ತರಣೆಯ ದಿಕ್ಕನ್ನು ವಿನ್ಯಾಸ ಹಂತದಲ್ಲಿ ಕನಸು ಕಾಣಲಾಗುವುದಿಲ್ಲ ಎಂಬ ನಿರೀಕ್ಷೆಯೊಂದಿಗೆ.
ಮತ್ತು ಹೌದು, ಒಂದು ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಈ ಎಲ್ಲಾ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುವುದು ಸಾಧ್ಯ (ಸಹಜವಾಗಿ, ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಮತ್ತು ಕೆಲವು ಮೀಸಲಾತಿಗಳೊಂದಿಗೆ).
ಕೆಳಗೆ ನಾನು ಡೇಟಾ ಗೋದಾಮುಗಳಿಗಾಗಿ ಎರಡು ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಚುರುಕುಬುದ್ಧಿಯ ವಿನ್ಯಾಸ ವಿಧಾನಗಳನ್ನು ಪರಿಗಣಿಸುತ್ತೇನೆ - ಆಂಕರ್ ಮಾದರಿ и ಡೇಟಾ ವಾಲ್ಟ್. ಬ್ರಾಕೆಟ್‌ಗಳಿಂದ ಹೊರಗುಳಿದಿರುವುದು ಅಂತಹ ಅತ್ಯುತ್ತಮ ತಂತ್ರಗಳು, ಉದಾಹರಣೆಗೆ, EAV, 6NF (ಅದರ ಶುದ್ಧ ರೂಪದಲ್ಲಿ) ಮತ್ತು NoSQL ಪರಿಹಾರಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲವೂ - ಅವು ಹೇಗಾದರೂ ಕೆಟ್ಟದಾಗಿರುವುದರಿಂದ ಅಲ್ಲ, ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ ಲೇಖನವು ಸ್ವಾಧೀನಪಡಿಸಿಕೊಳ್ಳಲು ಬೆದರಿಕೆ ಹಾಕುತ್ತದೆ. ಸರಾಸರಿ ಡಿಸರ್ನ ಪರಿಮಾಣ. ಇದು ಸ್ವಲ್ಪ ವಿಭಿನ್ನ ವರ್ಗದ ಪರಿಹಾರಗಳಿಗೆ ಸಂಬಂಧಿಸಿದೆ - ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನ ಒಟ್ಟಾರೆ ಆರ್ಕಿಟೆಕ್ಚರ್ (EAV ನಂತಹ) ಅಥವಾ ಜಾಗತಿಕವಾಗಿ ಇತರ ಮಾಹಿತಿ ಸಂಗ್ರಹಣೆ ಮಾದರಿಗಳಿಗೆ (ಗ್ರಾಫ್ ಡೇಟಾಬೇಸ್‌ಗಳಂತಹ) ನಿರ್ದಿಷ್ಟ ಸಂದರ್ಭಗಳಲ್ಲಿ ನೀವು ಬಳಸಬಹುದಾದ ತಂತ್ರಗಳಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ಮತ್ತು ಇತರ ಆಯ್ಕೆಗಳು NoSQL).
"ಶಾಸ್ತ್ರೀಯ" ವಿಧಾನದ ತೊಂದರೆಗಳು ಮತ್ತು ಹೊಂದಿಕೊಳ್ಳುವ ವಿಧಾನಗಳಲ್ಲಿ ಅವುಗಳ ಪರಿಹಾರಗಳು
"ಶಾಸ್ತ್ರೀಯ" ವಿಧಾನದಿಂದ ನಾನು ಉತ್ತಮ ಹಳೆಯ ನಕ್ಷತ್ರವನ್ನು ಅರ್ಥೈಸುತ್ತೇನೆ (ಆಧಾರಿತ ಪದರಗಳ ನಿರ್ದಿಷ್ಟ ಅನುಷ್ಠಾನವನ್ನು ಲೆಕ್ಕಿಸದೆ, ಕಿಂಬಾಲ್, ಇನ್ಮೋನ್ ಮತ್ತು CDM ನ ಅನುಯಾಯಿಗಳು ನನ್ನನ್ನು ಕ್ಷಮಿಸಲಿ).
1. ಸಂಪರ್ಕಗಳ ರಿಜಿಡ್ ಕಾರ್ಡಿನಾಲಿಟಿ
ಈ ಮಾದರಿಯು ಡೇಟಾದ ಸ್ಪಷ್ಟ ವಿಭಜನೆಯನ್ನು ಆಧರಿಸಿದೆ ಆಯಾಮ и ಸತ್ಯಗಳು. ಮತ್ತು ಇದು ತಾರ್ಕಿಕವಾಗಿದೆ - ಎಲ್ಲಾ ನಂತರ, ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಡೇಟಾ ವಿಶ್ಲೇಷಣೆಯು ಕೆಲವು ವಿಭಾಗಗಳಲ್ಲಿ (ಆಯಾಮಗಳು) ಕೆಲವು ಸಂಖ್ಯಾತ್ಮಕ ಸೂಚಕಗಳ (ಸತ್ಯಗಳು) ವಿಶ್ಲೇಷಣೆಗೆ ಬರುತ್ತದೆ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ವಸ್ತುಗಳ ನಡುವಿನ ಸಂಪರ್ಕಗಳನ್ನು ವಿದೇಶಿ ಕೀಲಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಕೋಷ್ಟಕಗಳ ನಡುವಿನ ಸಂಬಂಧಗಳ ರೂಪದಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ. ಇದು ಸಾಕಷ್ಟು ನೈಸರ್ಗಿಕವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ತಕ್ಷಣವೇ ನಮ್ಯತೆಯ ಮೊದಲ ಮಿತಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ - ಸಂಪರ್ಕಗಳ ಕಾರ್ಡಿನಾಲಿಟಿಯ ಕಟ್ಟುನಿಟ್ಟಾದ ವ್ಯಾಖ್ಯಾನ.
ಇದರರ್ಥ ಟೇಬಲ್ ವಿನ್ಯಾಸದ ಹಂತದಲ್ಲಿ, ಪ್ರತಿಯೊಂದು ಜೋಡಿ ಸಂಬಂಧಿತ ವಸ್ತುಗಳಿಗೆ ಅವು ಹಲವು-ಹಲವು, ಅಥವಾ ಕೇವಲ 1-ಹಲವು, ಮತ್ತು "ಯಾವ ದಿಕ್ಕಿನಲ್ಲಿ" ಸಂಬಂಧಿಸಬಹುದೇ ಎಂದು ನೀವು ನಿಖರವಾಗಿ ನಿರ್ಧರಿಸಬೇಕು. ಯಾವ ಟೇಬಲ್ ಪ್ರಾಥಮಿಕ ಕೀಲಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ ಮತ್ತು ಯಾವುದು ವಿದೇಶಿ ಕೀಲಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ ಎಂಬುದನ್ನು ಇದು ನೇರವಾಗಿ ನಿರ್ಧರಿಸುತ್ತದೆ. ಹೊಸ ಅವಶ್ಯಕತೆಗಳನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಈ ಮನೋಭಾವವನ್ನು ಬದಲಾಯಿಸುವುದು ಹೆಚ್ಚಾಗಿ ಬೇಸ್ನ ಪುನರ್ನಿರ್ಮಾಣಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಉದಾಹರಣೆಗೆ, "ನಗದು ರಶೀದಿ" ವಸ್ತುವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವಾಗ, ನೀವು ಮಾರಾಟ ವಿಭಾಗದ ಪ್ರಮಾಣಗಳನ್ನು ಅವಲಂಬಿಸಿ, ಕ್ರಿಯೆಯ ಸಾಧ್ಯತೆಯನ್ನು ಹಾಕಿದ್ದೀರಿ ಹಲವಾರು ಚೆಕ್ ಸ್ಥಾನಗಳಿಗೆ ಒಂದು ಬಡ್ತಿ (ಆದರೆ ಪ್ರತಿಯಾಗಿ ಅಲ್ಲ):
ಮತ್ತು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ಸಹೋದ್ಯೋಗಿಗಳು ಹೊಸ ಮಾರ್ಕೆಟಿಂಗ್ ತಂತ್ರವನ್ನು ಪರಿಚಯಿಸಿದರು, ಅದರಲ್ಲಿ ಅವರು ಅದೇ ಸ್ಥಾನದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಹಲವಾರು ಪ್ರಚಾರಗಳು. ಮತ್ತು ಈಗ ನೀವು ಸಂಬಂಧವನ್ನು ಪ್ರತ್ಯೇಕ ವಸ್ತುವಾಗಿ ಬೇರ್ಪಡಿಸುವ ಮೂಲಕ ಕೋಷ್ಟಕಗಳನ್ನು ಮಾರ್ಪಡಿಸಬೇಕಾಗಿದೆ.
(ಪ್ರಚಾರದ ಪರಿಶೀಲನೆಯು ಸೇರಿಕೊಂಡಿರುವ ಎಲ್ಲಾ ಮೂಲ ವಸ್ತುಗಳು ಈಗ ಸುಧಾರಿಸಬೇಕಾಗಿದೆ).
ಡೇಟಾ ವಾಲ್ಟ್ ಮತ್ತು ಆಂಕರ್ ಮಾದರಿಯಲ್ಲಿ ಸಂಬಂಧಗಳು
ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ತಪ್ಪಿಸುವುದು ತುಂಬಾ ಸರಳವಾಗಿದೆ: ಇದನ್ನು ಮಾಡಲು ನೀವು ಮಾರಾಟ ವಿಭಾಗವನ್ನು ನಂಬಬೇಕಾಗಿಲ್ಲ. ಎಲ್ಲಾ ಸಂಪರ್ಕಗಳನ್ನು ಆರಂಭದಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಹಲವು-ಹಲವು ಎಂದು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿ.
ಈ ವಿಧಾನವನ್ನು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ ಡಾನ್ ಲಿನ್ಸ್ಟೆಡ್ ಮಾದರಿಯ ಭಾಗವಾಗಿ ಡೇಟಾ ವಾಲ್ಟ್ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಬೆಂಬಲಿತವಾಗಿದೆ ಲಾರ್ಸ್ ರೋನ್‌ಬ್ಯಾಕ್ в ಆಂಕರ್ ಮಾದರಿ.
ಪರಿಣಾಮವಾಗಿ, ನಾವು ಹೊಂದಿಕೊಳ್ಳುವ ವಿಧಾನಗಳ ಮೊದಲ ವಿಶಿಷ್ಟ ಲಕ್ಷಣವನ್ನು ಪಡೆಯುತ್ತೇವೆ:
ವಸ್ತುಗಳ ನಡುವಿನ ಸಂಬಂಧಗಳನ್ನು ಪೋಷಕ ಘಟಕಗಳ ಗುಣಲಕ್ಷಣಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಅವು ಪ್ರತ್ಯೇಕ ರೀತಿಯ ವಸ್ತುಗಳಾಗಿವೆ.
В ಡೇಟಾ ವಾಲ್ಟ್ ಅಂತಹ ಲಿಂಕ್ ಮಾಡುವ ಕೋಷ್ಟಕಗಳನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಲಿಂಕ್, ಮತ್ತು ಸೈನ್ ಆಂಕರ್ ಮಾದರಿ - ಟೈ. ಮೊದಲ ನೋಟದಲ್ಲಿ, ಅವು ತುಂಬಾ ಹೋಲುತ್ತವೆ, ಆದರೂ ಅವುಗಳ ವ್ಯತ್ಯಾಸಗಳು ಹೆಸರಿನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ (ಇದನ್ನು ಕೆಳಗೆ ಚರ್ಚಿಸಲಾಗುವುದು). ಎರಡೂ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳಲ್ಲಿ, ಲಿಂಕ್ ಕೋಷ್ಟಕಗಳು ಲಿಂಕ್ ಮಾಡಬಹುದು ಯಾವುದೇ ಸಂಖ್ಯೆಯ ಘಟಕಗಳು (ಅಗತ್ಯವಿಲ್ಲ 2).
ಈ ಪುನರುಕ್ತಿ, ಮೊದಲ ನೋಟದಲ್ಲಿ, ಮಾರ್ಪಾಡುಗಳಿಗೆ ಗಮನಾರ್ಹ ನಮ್ಯತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಅಂತಹ ರಚನೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಲಿಂಕ್‌ಗಳ ಕಾರ್ಡಿನಾಲಿಟಿಯಲ್ಲಿನ ಬದಲಾವಣೆಗಳಿಗೆ ಮಾತ್ರವಲ್ಲದೆ ಹೊಸದನ್ನು ಸೇರಿಸುವುದಕ್ಕೂ ಸಹಿಷ್ಣುವಾಗುತ್ತದೆ - ಈಗ ಚೆಕ್ ಸ್ಥಾನವು ಅದನ್ನು ಭೇದಿಸಿದ ಕ್ಯಾಷಿಯರ್‌ಗೆ ಲಿಂಕ್ ಹೊಂದಿದ್ದರೆ, ಅಂತಹ ಲಿಂಕ್‌ನ ನೋಟವು ಸರಳವಾಗಿರುತ್ತದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಯಾವುದೇ ವಸ್ತುಗಳು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದಂತೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೋಷ್ಟಕಗಳ ಮೇಲೆ ಆಡ್-ಆನ್ ಆಗಿ.
2. ಡೇಟಾ ನಕಲು
ಹೊಂದಿಕೊಳ್ಳುವ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳಿಂದ ಪರಿಹರಿಸಲಾದ ಎರಡನೇ ಸಮಸ್ಯೆಯು ಕಡಿಮೆ ಸ್ಪಷ್ಟವಾಗಿದೆ ಮತ್ತು ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿ ಅಂತರ್ಗತವಾಗಿರುತ್ತದೆ. SCD2 ಮಾದರಿಯ ಅಳತೆಗಳು (ಎರಡನೆಯ ಪ್ರಕಾರದ ಆಯಾಮಗಳನ್ನು ನಿಧಾನವಾಗಿ ಬದಲಾಯಿಸುವುದು), ಆದರೂ ಅವುಗಳು ಮಾತ್ರವಲ್ಲ.
ಕ್ಲಾಸಿಕ್ ವೇರ್‌ಹೌಸ್‌ನಲ್ಲಿ, ಆಯಾಮವು ವಿಶಿಷ್ಟವಾಗಿ ಒಂದು ಟೇಬಲ್ ಆಗಿದ್ದು ಅದು ಬಾಡಿಗೆ ಕೀ (PK ಆಗಿ) ಮತ್ತು ಪ್ರತ್ಯೇಕ ಕಾಲಮ್‌ಗಳಲ್ಲಿ ವ್ಯಾಪಾರ ಕೀಗಳು ಮತ್ತು ಗುಣಲಕ್ಷಣಗಳ ಗುಂಪನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.
ಆಯಾಮವು ಆವೃತ್ತಿಯನ್ನು ಬೆಂಬಲಿಸಿದರೆ, ಆವೃತ್ತಿಯ ಮಾನ್ಯತೆಯ ಗಡಿಗಳನ್ನು ಪ್ರಮಾಣಿತ ಕ್ಷೇತ್ರಗಳ ಸೆಟ್‌ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಮೂಲದಲ್ಲಿನ ಒಂದು ಸಾಲಿಗೆ, ಹಲವಾರು ಆವೃತ್ತಿಗಳು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಗೋಚರಿಸುತ್ತವೆ (ಆವೃತ್ತಿಯ ಗುಣಲಕ್ಷಣಗಳಲ್ಲಿನ ಪ್ರತಿ ಬದಲಾವಣೆಗೆ ಒಂದು).
ಒಂದು ಆಯಾಮವು ಆಗಾಗ್ಗೆ ಬದಲಾಗುತ್ತಿರುವ ಆವೃತ್ತಿಯ ಗುಣಲಕ್ಷಣವನ್ನು ಹೊಂದಿದ್ದರೆ, ಅಂತಹ ಆಯಾಮದ ಆವೃತ್ತಿಗಳ ಸಂಖ್ಯೆಯು ಪ್ರಭಾವಶಾಲಿಯಾಗಿರುತ್ತದೆ (ಉಳಿದ ಗುಣಲಕ್ಷಣಗಳು ಆವೃತ್ತಿಯಾಗದಿದ್ದರೂ ಅಥವಾ ಎಂದಿಗೂ ಬದಲಾಗದಿದ್ದರೂ ಸಹ), ಮತ್ತು ಅಂತಹ ಹಲವಾರು ಗುಣಲಕ್ಷಣಗಳಿದ್ದರೆ, ಆವೃತ್ತಿಗಳ ಸಂಖ್ಯೆಯು ಮಾಡಬಹುದು ಅವರ ಸಂಖ್ಯೆಯಿಂದ ಘಾತೀಯವಾಗಿ ಬೆಳೆಯುತ್ತದೆ. ಈ ಆಯಾಮವು ಗಮನಾರ್ಹ ಪ್ರಮಾಣದ ಡಿಸ್ಕ್ ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಆದಾಗ್ಯೂ ಇದು ಸಂಗ್ರಹಿಸುವ ಹೆಚ್ಚಿನ ಡೇಟಾವು ಇತರ ಸಾಲುಗಳಿಂದ ಬದಲಾಯಿಸಲಾಗದ ಗುಣಲಕ್ಷಣದ ಮೌಲ್ಯಗಳ ನಕಲುಗಳಾಗಿವೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಇದನ್ನು ಹೆಚ್ಚಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ ಅಸಾಧಾರಣೀಕರಣ - ಕೆಲವು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮೌಲ್ಯವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ, ಮತ್ತು ಉಲ್ಲೇಖ ಪುಸ್ತಕ ಅಥವಾ ಇನ್ನೊಂದು ಆಯಾಮಕ್ಕೆ ಲಿಂಕ್ ಆಗಿ ಅಲ್ಲ. ಈ ವಿಧಾನವು ಡೇಟಾ ಪ್ರವೇಶವನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ, ಆಯಾಮವನ್ನು ಪ್ರವೇಶಿಸುವಾಗ ಸೇರ್ಪಡೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
ವಿಶಿಷ್ಟವಾಗಿ ಇದು ಕಾರಣವಾಗುತ್ತದೆ ಅದೇ ಮಾಹಿತಿಯನ್ನು ಹಲವಾರು ಸ್ಥಳಗಳಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನಿವಾಸದ ಪ್ರದೇಶ ಮತ್ತು ಕ್ಲೈಂಟ್‌ನ ವರ್ಗದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಏಕಕಾಲದಲ್ಲಿ “ಕ್ಲೈಂಟ್” ಆಯಾಮಗಳು ಮತ್ತು “ಖರೀದಿ”, “ವಿತರಣೆ” ಮತ್ತು “ಕಾಲ್ ಸೆಂಟರ್ ಕರೆಗಳು” ಸತ್ಯಗಳು, ಹಾಗೆಯೇ “ಕ್ಲೈಂಟ್ - ಕ್ಲೈಂಟ್ ಮ್ಯಾನೇಜರ್” ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು. "ಲಿಂಕ್ ಟೇಬಲ್.
ಸಾಮಾನ್ಯವಾಗಿ, ಮೇಲಿನ ವಿವರಣೆಯು ನಿಯಮಿತ (ಆವೃತ್ತಿಯಲ್ಲದ) ಆಯಾಮಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ, ಆದರೆ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಅವು ವಿಭಿನ್ನ ಪ್ರಮಾಣವನ್ನು ಹೊಂದಿರಬಹುದು: ವಸ್ತುವಿನ ಹೊಸ ಆವೃತ್ತಿಯ ಹೊರಹೊಮ್ಮುವಿಕೆ (ವಿಶೇಷವಾಗಿ ಹಿನ್ನೋಟದಲ್ಲಿ) ಎಲ್ಲಾ ಸಂಬಂಧಿತ ನವೀಕರಣಗಳಿಗೆ ಮಾತ್ರ ಕಾರಣವಾಗುತ್ತದೆ. ಕೋಷ್ಟಕಗಳು, ಆದರೆ ಸಂಬಂಧಿತ ವಸ್ತುಗಳ ಹೊಸ ಆವೃತ್ತಿಗಳ ಕ್ಯಾಸ್ಕೇಡಿಂಗ್ ನೋಟಕ್ಕೆ - ಟೇಬಲ್ 1 ಅನ್ನು ನಿರ್ಮಿಸಲು ಟೇಬಲ್ 2 ಅನ್ನು ಬಳಸಿದಾಗ ಮತ್ತು ಟೇಬಲ್ 2 ಅನ್ನು ನಿರ್ಮಿಸಲು ಟೇಬಲ್ 3 ಅನ್ನು ಬಳಸಿದಾಗ, ಇತ್ಯಾದಿ. ಟೇಬಲ್ 1 ರ ಒಂದು ಗುಣಲಕ್ಷಣವು ಟೇಬಲ್ 3 ರ ನಿರ್ಮಾಣದಲ್ಲಿ ತೊಡಗಿಸದಿದ್ದರೂ (ಮತ್ತು ಇತರ ಮೂಲಗಳಿಂದ ಪಡೆದ ಟೇಬಲ್ 2 ರ ಇತರ ಗುಣಲಕ್ಷಣಗಳು ಒಳಗೊಂಡಿರುತ್ತವೆ), ಈ ನಿರ್ಮಾಣದ ಆವೃತ್ತಿಯು ಕನಿಷ್ಟ ಹೆಚ್ಚುವರಿ ಓವರ್ಹೆಡ್ಗೆ ಕಾರಣವಾಗುತ್ತದೆ ಮತ್ತು ಗರಿಷ್ಠವಾಗಿ ಹೆಚ್ಚುವರಿ ಕೋಷ್ಟಕ 3 ರಲ್ಲಿನ ಆವೃತ್ತಿಗಳು. ಅದರೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ, ಮತ್ತು ಸರಪಳಿಯ ಕೆಳಗೆ.
3. ಪುನರ್ನಿರ್ಮಾಣದ ರೇಖಾತ್ಮಕವಲ್ಲದ ಸಂಕೀರ್ಣತೆ
ಅದೇ ಸಮಯದಲ್ಲಿ, ಇನ್ನೊಂದರ ಆಧಾರದ ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಪ್ರತಿ ಹೊಸ ಅಂಗಡಿ ಮುಂಭಾಗವು ETL ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದಾಗ ಡೇಟಾ "ವಿಪಥಗೊಳ್ಳುವ" ಸ್ಥಳಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಇದು ಪ್ರತಿಯಾಗಿ, ಪ್ರತಿ ನಂತರದ ಪರಿಷ್ಕರಣೆಯ ಸಂಕೀರ್ಣತೆ (ಮತ್ತು ಅವಧಿ) ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಮೇಲಿನವು ಅಪರೂಪವಾಗಿ ಮಾರ್ಪಡಿಸಿದ ETL ಪ್ರಕ್ರಿಯೆಗಳೊಂದಿಗೆ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ವಿವರಿಸಿದರೆ, ನೀವು ಅಂತಹ ಮಾದರಿಯಲ್ಲಿ ಬದುಕಬಹುದು - ಎಲ್ಲಾ ಸಂಬಂಧಿತ ವಸ್ತುಗಳಿಗೆ ಹೊಸ ಮಾರ್ಪಾಡುಗಳನ್ನು ಸರಿಯಾಗಿ ಮಾಡಲಾಗಿದೆಯೆ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಪರಿಷ್ಕರಣೆಗಳು ಆಗಾಗ್ಗೆ ಸಂಭವಿಸಿದಲ್ಲಿ, ಆಕಸ್ಮಿಕವಾಗಿ "ಕಾಣೆಯಾದ" ಹಲವಾರು ಸಂಪರ್ಕಗಳ ಸಾಧ್ಯತೆಯು ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, "ಆವೃತ್ತಿಯ" ಇಟಿಎಲ್ "ಆವೃತ್ತಿಯಲ್ಲದ" ಒಂದಕ್ಕಿಂತ ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ ಎಂದು ನಾವು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡರೆ, ಈ ಸಂಪೂರ್ಣ ಸೌಲಭ್ಯವನ್ನು ಆಗಾಗ್ಗೆ ನವೀಕರಿಸುವಾಗ ತಪ್ಪುಗಳನ್ನು ತಪ್ಪಿಸುವುದು ತುಂಬಾ ಕಷ್ಟವಾಗುತ್ತದೆ.
ಡೇಟಾ ವಾಲ್ಟ್ ಮತ್ತು ಆಂಕರ್ ಮಾದರಿಯಲ್ಲಿ ವಸ್ತುಗಳು ಮತ್ತು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು
ಹೊಂದಿಕೊಳ್ಳುವ ವಾಸ್ತುಶಿಲ್ಪದ ಲೇಖಕರು ಪ್ರಸ್ತಾಪಿಸಿದ ವಿಧಾನವನ್ನು ಈ ಕೆಳಗಿನಂತೆ ರೂಪಿಸಬಹುದು:
ಯಾವ ಬದಲಾವಣೆಗಳು ಒಂದೇ ಆಗಿರುತ್ತವೆ ಎಂಬುದನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು ಅವಶ್ಯಕ. ಅಂದರೆ, ಗುಣಲಕ್ಷಣಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಕೀಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ.
ಆದಾಗ್ಯೂ, ಒಬ್ಬರು ಗೊಂದಲಕ್ಕೀಡಾಗಬಾರದು ಆವೃತ್ತಿಯಾಗಿಲ್ಲ ಜೊತೆ ಗುಣಲಕ್ಷಣ ಬದಲಾಗದೆ: ಮೊದಲನೆಯದು ಅದರ ಬದಲಾವಣೆಗಳ ಇತಿಹಾಸವನ್ನು ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ, ಆದರೆ ಬದಲಾಯಿಸಬಹುದು (ಉದಾಹರಣೆಗೆ, ಇನ್ಪುಟ್ ದೋಷವನ್ನು ಸರಿಪಡಿಸುವಾಗ ಅಥವಾ ಹೊಸ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವಾಗ); ಎರಡನೆಯದು ಎಂದಿಗೂ ಬದಲಾಗುವುದಿಲ್ಲ.
ಡೇಟಾ ವಾಲ್ಟ್ ಮತ್ತು ಆಂಕರ್ ಮಾದರಿಯಲ್ಲಿ ನಿಖರವಾಗಿ ಏನನ್ನು ಬದಲಾಯಿಸಲಾಗದು ಎಂದು ಪರಿಗಣಿಸಬಹುದು ಎಂಬುದರ ಕುರಿತು ದೃಷ್ಟಿಕೋನಗಳು ಭಿನ್ನವಾಗಿರುತ್ತವೆ.
ವಾಸ್ತುಶಿಲ್ಪದ ದೃಷ್ಟಿಕೋನದಿಂದ ಡೇಟಾ ವಾಲ್ಟ್, ಬದಲಾಗದೆ ಪರಿಗಣಿಸಬಹುದು ಕೀಗಳ ಸಂಪೂರ್ಣ ಸೆಟ್ - ನೈಸರ್ಗಿಕ (ಸಂಸ್ಥೆಯ TIN, ಮೂಲ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಉತ್ಪನ್ನ ಕೋಡ್, ಇತ್ಯಾದಿ) ಮತ್ತು ಬಾಡಿಗೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಉಳಿದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಮೂಲ ಮತ್ತು/ಅಥವಾ ಬದಲಾವಣೆಗಳ ಆವರ್ತನದ ಪ್ರಕಾರ ಗುಂಪುಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು ಮತ್ತು ಪ್ರತಿ ಗುಂಪಿಗೆ ಪ್ರತ್ಯೇಕ ಕೋಷ್ಟಕವನ್ನು ನಿರ್ವಹಿಸಿ ಸ್ವತಂತ್ರ ಆವೃತ್ತಿಗಳೊಂದಿಗೆ.
ಮಾದರಿಯಲ್ಲಿ ಆಂಕರ್ ಮಾದರಿ ಬದಲಾಗದೆ ಪರಿಗಣಿಸಲಾಗಿದೆ ಬಾಡಿಗೆ ಕೀಲಿ ಮಾತ್ರ ಸಾರ. ಉಳಿದಂತೆ (ನೈಸರ್ಗಿಕ ಕೀಗಳನ್ನು ಒಳಗೊಂಡಂತೆ) ಅದರ ಗುಣಲಕ್ಷಣಗಳ ವಿಶೇಷ ಪ್ರಕರಣವಾಗಿದೆ. ಇದರಲ್ಲಿ ಎಲ್ಲಾ ಗುಣಲಕ್ಷಣಗಳು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಪರಸ್ಪರ ಸ್ವತಂತ್ರವಾಗಿರುತ್ತವೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಗುಣಲಕ್ಷಣಕ್ಕೆ a ಪ್ರತ್ಯೇಕ ಟೇಬಲ್.
В ಡೇಟಾ ವಾಲ್ಟ್ ಘಟಕದ ಕೀಲಿಗಳನ್ನು ಹೊಂದಿರುವ ಕೋಷ್ಟಕಗಳನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಹುಬಾಮಿ. ಹಬ್‌ಗಳು ಯಾವಾಗಲೂ ಸ್ಥಿರವಾದ ಕ್ಷೇತ್ರಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ:
- ನೈಸರ್ಗಿಕ ಘಟಕದ ಕೀಗಳು
- ಬಾಡಿಗೆ ಕೀ
- ಮೂಲಕ್ಕೆ ಲಿಂಕ್ ಮಾಡಿ
- ರೆಕಾರ್ಡ್ ಸೇರಿಸುವ ಸಮಯ
ಹಬ್ಸ್‌ನಲ್ಲಿ ಪೋಸ್ಟ್‌ಗಳು ಎಂದಿಗೂ ಬದಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಆವೃತ್ತಿಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಬಾಹ್ಯವಾಗಿ, ಬದಲಿಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ಕೆಲವು ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಬಳಸಲಾಗುವ ಐಡಿ-ಮ್ಯಾಪ್ ಪ್ರಕಾರದ ಕೋಷ್ಟಕಗಳಿಗೆ ಹಬ್‌ಗಳು ಹೋಲುತ್ತವೆ, ಆದಾಗ್ಯೂ, ಡೇಟಾ ವಾಲ್ಟ್‌ನಲ್ಲಿ ಬಾಡಿಗೆಗಳಾಗಿ ವ್ಯಾಪಾರ ಕೀಗಳ ಗುಂಪಿನಿಂದ ಹ್ಯಾಶ್ ಅನ್ನು ಬಳಸಲು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ. ಈ ವಿಧಾನವು ಮೂಲಗಳಿಂದ ಲೋಡ್ ಸಂಬಂಧಗಳು ಮತ್ತು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ (ಬಾಡಿಗೆಯನ್ನು ಪಡೆಯಲು ಹಬ್‌ಗೆ ಸೇರುವ ಅಗತ್ಯವಿಲ್ಲ, ನೈಸರ್ಗಿಕ ಕೀಲಿಯ ಹ್ಯಾಶ್ ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ), ಆದರೆ ಇತರ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು (ಉದಾಹರಣೆಗೆ, ಘರ್ಷಣೆಗಳು, ಪ್ರಕರಣ ಮತ್ತು ಮುದ್ರಿಸಲಾಗದವುಗಳಿಗೆ ಸಂಬಂಧಿಸಿದೆ ಸ್ಟ್ರಿಂಗ್ ಕೀಗಳಲ್ಲಿನ ಅಕ್ಷರಗಳು, ಇತ್ಯಾದಿ. .p.), ಆದ್ದರಿಂದ ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ವೀಕರಿಸಲಾಗುವುದಿಲ್ಲ.
ಎಲ್ಲಾ ಇತರ ಘಟಕ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಎಂಬ ವಿಶೇಷ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಉಪಗ್ರಹಗಳು. ಒಂದು ಕೇಂದ್ರವು ಹಲವಾರು ಉಪಗ್ರಹಗಳನ್ನು ವಿವಿಧ ಸೆಟ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು.
ಉಪಗ್ರಹಗಳ ನಡುವೆ ಗುಣಲಕ್ಷಣಗಳ ವಿತರಣೆಯು ತತ್ವದ ಪ್ರಕಾರ ಸಂಭವಿಸುತ್ತದೆ ಜಂಟಿ ಬದಲಾವಣೆ — ಒಂದು ಉಪಗ್ರಹದಲ್ಲಿ ಆವೃತ್ತಿಯಿಲ್ಲದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು (ಉದಾಹರಣೆಗೆ, ಒಬ್ಬ ವ್ಯಕ್ತಿಗೆ ಹುಟ್ಟಿದ ದಿನಾಂಕ ಮತ್ತು SNILS), ಇನ್ನೊಂದರಲ್ಲಿ - ಅಪರೂಪವಾಗಿ ಬದಲಾಗುತ್ತಿರುವ ಆವೃತ್ತಿಗಳು (ಉದಾಹರಣೆಗೆ, ಕೊನೆಯ ಹೆಸರು ಮತ್ತು ಪಾಸ್‌ಪೋರ್ಟ್ ಸಂಖ್ಯೆ), ಮೂರನೆಯದರಲ್ಲಿ - ಆಗಾಗ್ಗೆ ಬದಲಾಗುತ್ತಿರುವವು (ಉದಾಹರಣೆಗೆ, ವಿತರಣಾ ವಿಳಾಸ, ವರ್ಗ, ಕೊನೆಯ ಆದೇಶದ ದಿನಾಂಕ, ಇತ್ಯಾದಿ). ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಆವೃತ್ತಿಯನ್ನು ಪ್ರತ್ಯೇಕ ಉಪಗ್ರಹಗಳ ಮಟ್ಟದಲ್ಲಿ ನಡೆಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಒಟ್ಟಾರೆಯಾಗಿ ಘಟಕವಲ್ಲ, ಆದ್ದರಿಂದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ವಿತರಿಸಲು ಸಲಹೆ ನೀಡಲಾಗುತ್ತದೆ ಇದರಿಂದ ಒಂದು ಉಪಗ್ರಹದೊಳಗಿನ ಆವೃತ್ತಿಗಳ ಛೇದಕವು ಕನಿಷ್ಠವಾಗಿರುತ್ತದೆ (ಇದು ಸಂಗ್ರಹವಾಗಿರುವ ಆವೃತ್ತಿಗಳ ಒಟ್ಟು ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. )
ಅಲ್ಲದೆ, ಡೇಟಾ ಲೋಡಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು, ವಿವಿಧ ಮೂಲಗಳಿಂದ ಪಡೆದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತ್ಯೇಕ ಉಪಗ್ರಹಗಳಲ್ಲಿ ಸೇರಿಸಲಾಗುತ್ತದೆ.
ಉಪಗ್ರಹಗಳು ಹಬ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ ವಿದೇಶಿ ಕೀ (ಇದು 1 ರಿಂದ ಅನೇಕ ಕಾರ್ಡಿನಾಲಿಟಿಗೆ ಅನುರೂಪವಾಗಿದೆ). ಇದರರ್ಥ ಬಹು ಗುಣಲಕ್ಷಣ ಮೌಲ್ಯಗಳು (ಉದಾಹರಣೆಗೆ, ಒಂದು ಕ್ಲೈಂಟ್‌ಗಾಗಿ ಬಹು ಸಂಪರ್ಕ ಫೋನ್ ಸಂಖ್ಯೆಗಳು) ಈ "ಡೀಫಾಲ್ಟ್" ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಿಂದ ಬೆಂಬಲಿತವಾಗಿದೆ.
В ಆಂಕರ್ ಮಾದರಿ ಕೀಲಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಕೋಷ್ಟಕಗಳನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಆಂಕರ್‌ಗಳು. ಮತ್ತು ಅವರು ಇಡುತ್ತಾರೆ:
- ಬಾಡಿಗೆ ಕೀಲಿಗಳು ಮಾತ್ರ
- ಮೂಲಕ್ಕೆ ಲಿಂಕ್ ಮಾಡಿ
- ರೆಕಾರ್ಡ್ ಸೇರಿಸುವ ಸಮಯ
ಆಂಕರ್ ಮಾದರಿಯ ದೃಷ್ಟಿಕೋನದಿಂದ ನೈಸರ್ಗಿಕ ಕೀಲಿಗಳನ್ನು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಸಾಮಾನ್ಯ ಗುಣಲಕ್ಷಣಗಳು. ಈ ಆಯ್ಕೆಯು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಹೆಚ್ಚು ಕಷ್ಟಕರವೆಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಇದು ವಸ್ತುವನ್ನು ಗುರುತಿಸಲು ಹೆಚ್ಚಿನ ಅವಕಾಶವನ್ನು ನೀಡುತ್ತದೆ.
ಉದಾಹರಣೆಗೆ, ಒಂದೇ ಅಸ್ತಿತ್ವದ ಬಗ್ಗೆ ಡೇಟಾವು ವಿಭಿನ್ನ ಸಿಸ್ಟಮ್‌ಗಳಿಂದ ಬರಬಹುದಾದರೆ, ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ನೈಸರ್ಗಿಕ ಕೀಲಿಯನ್ನು ಬಳಸುತ್ತದೆ. ಡೇಟಾ ವಾಲ್ಟ್‌ನಲ್ಲಿ, ಇದು ಹಲವಾರು ಹಬ್‌ಗಳ ಬದಲಿಗೆ ತೊಡಕಿನ ರಚನೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು (ಪ್ರತಿ ಮೂಲಕ್ಕೆ ಒಂದು + ಏಕೀಕರಿಸುವ ಮಾಸ್ಟರ್ ಆವೃತ್ತಿ), ಆದರೆ ಆಂಕರ್ ಮಾದರಿಯಲ್ಲಿ, ಪ್ರತಿ ಮೂಲದ ನೈಸರ್ಗಿಕ ಕೀ ತನ್ನದೇ ಆದ ಗುಣಲಕ್ಷಣಕ್ಕೆ ಸೇರುತ್ತದೆ ಮತ್ತು ಸ್ವತಂತ್ರವಾಗಿ ಲೋಡ್ ಮಾಡುವಾಗ ಬಳಸಬಹುದು ಎಲ್ಲಾ ಇತರರು.
ಆದರೆ ಇಲ್ಲಿ ಒಂದು ಕಪಟ ಅಂಶವೂ ಇದೆ: ವಿಭಿನ್ನ ವ್ಯವಸ್ಥೆಗಳಿಂದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಒಂದು ಘಟಕದಲ್ಲಿ ಸಂಯೋಜಿಸಿದರೆ, ಹೆಚ್ಚಾಗಿ ಕೆಲವು ಇವೆ "ಅಂಟಿಸುವ" ನಿಯಮಗಳು, ವಿವಿಧ ಮೂಲಗಳಿಂದ ದಾಖಲೆಗಳು ಅಸ್ತಿತ್ವದ ಒಂದು ನಿದರ್ಶನಕ್ಕೆ ಅನುಗುಣವಾಗಿರುತ್ತವೆ ಎಂದು ಸಿಸ್ಟಮ್ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.
В ಡೇಟಾ ವಾಲ್ಟ್ ಈ ನಿಯಮಗಳು ಹೆಚ್ಚಾಗಿ ರಚನೆಯನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ ಮಾಸ್ಟರ್ ಘಟಕದ "ಬಾಡಿಗೆ ಕೇಂದ್ರ" ಮತ್ತು ನೈಸರ್ಗಿಕ ಮೂಲ ಕೀಗಳನ್ನು ಮತ್ತು ಅವುಗಳ ಮೂಲ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಹಬ್‌ಗಳ ಮೇಲೆ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪ್ರಭಾವ ಬೀರುವುದಿಲ್ಲ. ಕೆಲವು ಹಂತದಲ್ಲಿ ವಿಲೀನಗೊಳಿಸುವ ನಿಯಮಗಳು ಬದಲಾದರೆ (ಅಥವಾ ಅದನ್ನು ನಿರ್ವಹಿಸುವ ಗುಣಲಕ್ಷಣಗಳನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತದೆ), ಬಾಡಿಗೆ ಕೇಂದ್ರಗಳನ್ನು ಮರುಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಲು ಇದು ಸಾಕಾಗುತ್ತದೆ.
В ಆಂಕರ್ ಮಾದರಿ ಅಂತಹ ಘಟಕವನ್ನು ಹೆಚ್ಚಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಏಕೈಕ ಆಂಕರ್. ಇದರರ್ಥ ಎಲ್ಲಾ ಗುಣಲಕ್ಷಣಗಳು, ಅವು ಯಾವುದೇ ಮೂಲದಿಂದ ಬಂದಿದ್ದರೂ, ಅದೇ ಪರ್ಯಾಯಕ್ಕೆ ಬದ್ಧವಾಗಿರುತ್ತವೆ. ತಪ್ಪಾಗಿ ವಿಲೀನಗೊಂಡ ದಾಖಲೆಗಳನ್ನು ಬೇರ್ಪಡಿಸುವುದು ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ಅಂತಹ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ವಿಲೀನಗೊಳಿಸುವಿಕೆಯ ಪ್ರಸ್ತುತತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ, ವಿಶೇಷವಾಗಿ ನಿಯಮಗಳು ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿದ್ದರೆ ಮತ್ತು ಆಗಾಗ್ಗೆ ಬದಲಾಗುತ್ತಿದ್ದರೆ ಮತ್ತು ಅದೇ ಗುಣಲಕ್ಷಣವನ್ನು ವಿವಿಧ ಮೂಲಗಳಿಂದ ಪಡೆಯಬಹುದು (ಇದು ಖಂಡಿತವಾಗಿಯೂ ಸಾಧ್ಯ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದು ಗುಣಲಕ್ಷಣದ ಆವೃತ್ತಿಯು ಅದರ ಮೂಲಕ್ಕೆ ಲಿಂಕ್ ಅನ್ನು ಉಳಿಸಿಕೊಂಡಿದೆ).
ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾದರೆ ಡಿಪ್ಲಿಕೇಶನ್, ವಿಲೀನ ದಾಖಲೆಗಳು ಮತ್ತು ಇತರ MDM ಅಂಶಗಳು, ಚುರುಕುಬುದ್ಧಿಯ ವಿಧಾನಗಳಲ್ಲಿ ನೈಸರ್ಗಿಕ ಕೀಲಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಅಂಶಗಳಿಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಗಮನ ಕೊಡುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ವಿಲೀನ ದೋಷಗಳ ವಿಷಯದಲ್ಲಿ ಬೃಹತ್ ಡೇಟಾ ವಾಲ್ಟ್ ವಿನ್ಯಾಸವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಸುರಕ್ಷಿತವಾಗಿರುವ ಸಾಧ್ಯತೆಯಿದೆ.
ಆಂಕರ್ ಮಾದರಿ ಎಂಬ ಹೆಚ್ಚುವರಿ ವಸ್ತು ಪ್ರಕಾರವನ್ನು ಸಹ ಒದಗಿಸುತ್ತದೆ ಗಂಟು ಇದು ಮೂಲಭೂತವಾಗಿ ವಿಶೇಷವಾಗಿದೆ ಕ್ಷೀಣಗೊಳ್ಳುವ ಆಂಕರ್ ಪ್ರಕಾರ, ಇದು ಕೇವಲ ಒಂದು ಗುಣಲಕ್ಷಣವನ್ನು ಹೊಂದಿರಬಹುದು. ಫ್ಲಾಟ್ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನೋಡ್‌ಗಳನ್ನು ಬಳಸಬೇಕು (ಉದಾಹರಣೆಗೆ, ಲಿಂಗ, ವೈವಾಹಿಕ ಸ್ಥಿತಿ, ಗ್ರಾಹಕ ಸೇವಾ ವರ್ಗ, ಇತ್ಯಾದಿ). ಆಂಕರ್‌ಗಿಂತ ಭಿನ್ನವಾಗಿ, ಗಂಟು ಯಾವುದೇ ಸಂಬಂಧಿತ ಗುಣಲಕ್ಷಣ ಕೋಷ್ಟಕಗಳನ್ನು ಹೊಂದಿಲ್ಲ, ಮತ್ತು ಅದರ ಏಕೈಕ ಗುಣಲಕ್ಷಣ (ಹೆಸರು) ಯಾವಾಗಲೂ ಕೀಲಿಯೊಂದಿಗೆ ಒಂದೇ ಕೋಷ್ಟಕದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಆಂಕರ್‌ಗಳು ಪರಸ್ಪರ ಸಂಪರ್ಕ ಹೊಂದಿದ ರೀತಿಯಲ್ಲಿಯೇ ಟೈ ಟೇಬಲ್‌ಗಳ (ಟೈ) ಮೂಲಕ ಆಂಕರ್‌ಗಳಿಗೆ ನೋಡ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸಲಾಗಿದೆ.
ನೋಡ್‌ಗಳ ಬಳಕೆಯ ಬಗ್ಗೆ ಯಾವುದೇ ಸ್ಪಷ್ಟ ಅಭಿಪ್ರಾಯವಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, , ರಷ್ಯಾದಲ್ಲಿ ಆಂಕರ್ ಮಾದರಿಯ ಬಳಕೆಯನ್ನು ಸಕ್ರಿಯವಾಗಿ ಪ್ರಚಾರ ಮಾಡುವವರು, ಒಂದೇ ಒಂದು ಉಲ್ಲೇಖ ಪುಸ್ತಕಕ್ಕಾಗಿ ಅದನ್ನು ಖಚಿತವಾಗಿ ಹೇಳಲಾಗುವುದಿಲ್ಲ ಎಂದು ನಂಬುತ್ತಾರೆ (ಅಸಮಂಜಸವಲ್ಲ). ಯಾವಾಗಲೂ ಸ್ಥಿರ ಮತ್ತು ಏಕ-ಹಂತವಾಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಎಲ್ಲಾ ವಸ್ತುಗಳಿಗೆ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಆಂಕರ್ ಅನ್ನು ತಕ್ಷಣವೇ ಬಳಸುವುದು ಉತ್ತಮ.
ಡೇಟಾ ವಾಲ್ಟ್ ಮತ್ತು ಆಂಕರ್ ಮಾದರಿಯ ನಡುವಿನ ಮತ್ತೊಂದು ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಲಭ್ಯತೆ ಸಂಪರ್ಕಗಳ ಗುಣಲಕ್ಷಣಗಳು:
В ಡೇಟಾ ವಾಲ್ಟ್ ಲಿಂಕ್‌ಗಳು ಹಬ್‌ಗಳಂತೆಯೇ ಪೂರ್ಣ ಪ್ರಮಾಣದ ವಸ್ತುಗಳಾಗಿವೆ ಮತ್ತು ಹೊಂದಬಹುದು ಸ್ವಂತ ಗುಣಲಕ್ಷಣಗಳು. ದಿ ಆಂಕರ್ ಮಾದರಿ ಆಂಕರ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸಲು ಮಾತ್ರ ಲಿಂಕ್‌ಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ತಮ್ಮದೇ ಆದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ವ್ಯತ್ಯಾಸವು ಗಮನಾರ್ಹವಾಗಿ ವಿಭಿನ್ನ ಮಾಡೆಲಿಂಗ್ ವಿಧಾನಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ ಸತ್ಯಗಳು, ಇದನ್ನು ಮತ್ತಷ್ಟು ಚರ್ಚಿಸಲಾಗುವುದು.
ಸತ್ಯ ಸಂಗ್ರಹಣೆ
ಇದಕ್ಕೂ ಮೊದಲು, ನಾವು ಮುಖ್ಯವಾಗಿ ಮಾಪನ ಮಾಡೆಲಿಂಗ್ ಬಗ್ಗೆ ಮಾತನಾಡಿದ್ದೇವೆ. ಸತ್ಯಗಳು ಸ್ವಲ್ಪ ಕಡಿಮೆ ಸ್ಪಷ್ಟವಾಗಿವೆ.
В ಡೇಟಾ ವಾಲ್ಟ್ ಸತ್ಯಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಒಂದು ವಿಶಿಷ್ಟ ವಸ್ತುವಾಗಿದೆ ಲಿಂಕ್, ಯಾರ ಉಪಗ್ರಹಗಳಲ್ಲಿ ನೈಜ ಸೂಚಕಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ.
ಈ ವಿಧಾನವು ಅರ್ಥಗರ್ಭಿತವೆಂದು ತೋರುತ್ತದೆ. ಇದು ವಿಶ್ಲೇಷಿಸಿದ ಸೂಚಕಗಳಿಗೆ ಸುಲಭ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಸಾಂಪ್ರದಾಯಿಕ ಫ್ಯಾಕ್ಟ್ ಟೇಬಲ್‌ಗೆ ಹೋಲುತ್ತದೆ (ಸೂಚಕಗಳನ್ನು ಮಾತ್ರ ಟೇಬಲ್‌ನಲ್ಲಿ ಅಲ್ಲ, ಆದರೆ "ನೆರೆಹೊರೆಯ" ಒಂದರಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ). ಆದರೆ ಮೋಸಗಳೂ ಇವೆ: ಮಾದರಿಯ ವಿಶಿಷ್ಟ ಮಾರ್ಪಾಡುಗಳಲ್ಲಿ ಒಂದು - ಫ್ಯಾಕ್ಟ್ ಕೀ ವಿಸ್ತರಣೆ - ಅಗತ್ಯ ಲಿಂಕ್‌ಗೆ ಹೊಸ ವಿದೇಶಿ ಕೀಲಿಯನ್ನು ಸೇರಿಸಲಾಗುತ್ತಿದೆ. ಮತ್ತು ಇದು ಪ್ರತಿಯಾಗಿ, ಮಾಡ್ಯುಲಾರಿಟಿಯನ್ನು "ಮುರಿಯುತ್ತದೆ" ಮತ್ತು ಇತರ ವಸ್ತುಗಳಿಗೆ ಮಾರ್ಪಾಡುಗಳ ಅಗತ್ಯವನ್ನು ಸಂಭಾವ್ಯವಾಗಿ ಉಂಟುಮಾಡುತ್ತದೆ.
В ಆಂಕರ್ ಮಾದರಿ ಸಂಪರ್ಕವು ತನ್ನದೇ ಆದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಈ ವಿಧಾನವು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ - ಸಂಪೂರ್ಣವಾಗಿ ಎಲ್ಲಾ ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ಸೂಚಕಗಳನ್ನು ಒಂದು ನಿರ್ದಿಷ್ಟ ಆಂಕರ್‌ಗೆ ಲಿಂಕ್ ಮಾಡಬೇಕು. ಇದರ ತೀರ್ಮಾನವು ಸರಳವಾಗಿದೆ - ಪ್ರತಿಯೊಂದು ಸಂಗತಿಗೂ ತನ್ನದೇ ಆದ ಆಧಾರ ಬೇಕು. ನಾವು ಸತ್ಯವೆಂದು ಗ್ರಹಿಸಲು ಬಳಸಿದ ಕೆಲವು ಸಂಗತಿಗಳಿಗೆ, ಇದು ಸ್ವಾಭಾವಿಕವಾಗಿ ಕಾಣಿಸಬಹುದು - ಉದಾಹರಣೆಗೆ, ಖರೀದಿಯ ಸಂಗತಿಯನ್ನು "ಆದೇಶ" ಅಥವಾ "ರಶೀದಿ", ಸೆಷನ್‌ಗೆ ಸೈಟ್‌ಗೆ ಭೇಟಿ ನೀಡುವುದು ಇತ್ಯಾದಿಗಳಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದು. ಆದರೆ ಅಂತಹ ನೈಸರ್ಗಿಕ “ವಾಹಕ ವಸ್ತು” ವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಅಷ್ಟು ಸುಲಭವಲ್ಲದ ಸಂಗತಿಗಳೂ ಇವೆ - ಉದಾಹರಣೆಗೆ, ಪ್ರತಿ ದಿನದ ಆರಂಭದಲ್ಲಿ ಗೋದಾಮುಗಳಲ್ಲಿನ ಸರಕುಗಳ ಅವಶೇಷಗಳು.
ಅಂತೆಯೇ, ಆಂಕರ್ ಮಾದರಿಯಲ್ಲಿ ಫ್ಯಾಕ್ಟ್ ಕೀಲಿಯನ್ನು ವಿಸ್ತರಿಸುವಾಗ ಮಾಡ್ಯುಲಾರಿಟಿ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸುವುದಿಲ್ಲ (ಅನುಗುಣವಾದ ಆಂಕರ್‌ಗೆ ಹೊಸ ಸಂಬಂಧವನ್ನು ಸೇರಿಸಲು ಸಾಕು), ಆದರೆ ಸತ್ಯಗಳನ್ನು ಪ್ರದರ್ಶಿಸಲು ಮಾದರಿಯನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದು ಕಡಿಮೆ ನಿಸ್ಸಂದಿಗ್ಧವಾಗಿರುತ್ತದೆ; "ಕೃತಕ" ಆಂಕರ್‌ಗಳು ಕಾಣಿಸಿಕೊಳ್ಳಬಹುದು. ಅದು ವ್ಯಾಪಾರ ವಸ್ತುವಿನ ಮಾದರಿಯನ್ನು ಅಸ್ಪಷ್ಟ ರೀತಿಯಲ್ಲಿ ಪ್ರದರ್ಶಿಸುತ್ತದೆ.
ನಮ್ಯತೆಯನ್ನು ಹೇಗೆ ಸಾಧಿಸಲಾಗುತ್ತದೆ
ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಪರಿಣಾಮವಾಗಿ ನಿರ್ಮಾಣವು ಒಳಗೊಂಡಿದೆ ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚು ಕೋಷ್ಟಕಗಳುಸಾಂಪ್ರದಾಯಿಕ ಅಳತೆಗಿಂತ. ಆದರೆ ಇದು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಡಿಸ್ಕ್ ಜಾಗ ಸಾಂಪ್ರದಾಯಿಕ ಆಯಾಮದಂತೆ ಅದೇ ಆವೃತ್ತಿಯ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಇಲ್ಲಿ ಯಾವುದೇ ಮ್ಯಾಜಿಕ್ ಇಲ್ಲ - ಇದು ಸಾಮಾನ್ಯೀಕರಣದ ಬಗ್ಗೆ. ಉಪಗ್ರಹಗಳು (ಡೇಟಾ ವಾಲ್ಟ್‌ನಲ್ಲಿ) ಅಥವಾ ಪ್ರತ್ಯೇಕ ಕೋಷ್ಟಕಗಳಲ್ಲಿ (ಆಂಕರ್ ಮಾಡೆಲ್) ಗುಣಲಕ್ಷಣಗಳನ್ನು ವಿತರಿಸುವ ಮೂಲಕ, ನಾವು ಕಡಿಮೆಗೊಳಿಸುತ್ತೇವೆ (ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತೇವೆ) ಇತರವನ್ನು ಬದಲಾಯಿಸುವಾಗ ಕೆಲವು ಗುಣಲಕ್ಷಣಗಳ ಮೌಲ್ಯಗಳ ನಕಲು.
ಗೆ ಡೇಟಾ ವಾಲ್ಟ್ ಗೆಲುವು ಉಪಗ್ರಹಗಳ ನಡುವಿನ ಗುಣಲಕ್ಷಣಗಳ ವಿತರಣೆಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ, ಮತ್ತು ಆಂಕರ್ ಮಾದರಿ - ಪ್ರತಿ ಮಾಪನ ವಸ್ತುವಿನ ಆವೃತ್ತಿಗಳ ಸರಾಸರಿ ಸಂಖ್ಯೆಗೆ ಬಹುತೇಕ ನೇರವಾಗಿ ಅನುಪಾತದಲ್ಲಿರುತ್ತದೆ.
ಆದಾಗ್ಯೂ, ಬಾಹ್ಯಾಕಾಶ ಉಳಿತಾಯವು ಮುಖ್ಯವಾಗಿದೆ, ಆದರೆ ಮುಖ್ಯವಲ್ಲ, ಗುಣಲಕ್ಷಣಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಗ್ರಹಿಸುವ ಪ್ರಯೋಜನ. ಸಂಬಂಧಗಳ ಪ್ರತ್ಯೇಕ ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ, ಈ ವಿಧಾನವು ಅಂಗಡಿಯನ್ನು ಮಾಡುತ್ತದೆ ಮಾಡ್ಯುಲರ್ ವಿನ್ಯಾಸ. ಇದರರ್ಥ ಅಂತಹ ಮಾದರಿಯಲ್ಲಿ ವೈಯಕ್ತಿಕ ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ಸಂಪೂರ್ಣ ಹೊಸ ವಿಷಯ ಕ್ಷೇತ್ರಗಳನ್ನು ಸೇರಿಸುವುದು ತೋರುತ್ತಿದೆ ಸೂಪರ್ಸ್ಟ್ರಕ್ಚರ್ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವಸ್ತುಗಳ ಮೇಲೆ ಅವುಗಳನ್ನು ಬದಲಾಯಿಸದೆಯೇ. ಮತ್ತು ಇದು ನಿಖರವಾಗಿ ವಿವರಿಸಿದ ವಿಧಾನಗಳನ್ನು ಹೊಂದಿಕೊಳ್ಳುವಂತೆ ಮಾಡುತ್ತದೆ.
ಇದು ತುಂಡು ಉತ್ಪಾದನೆಯಿಂದ ಸಾಮೂಹಿಕ ಉತ್ಪಾದನೆಗೆ ಪರಿವರ್ತನೆಯನ್ನು ಹೋಲುತ್ತದೆ - ಸಾಂಪ್ರದಾಯಿಕ ವಿಧಾನದಲ್ಲಿ ಮಾದರಿಯ ಪ್ರತಿಯೊಂದು ಕೋಷ್ಟಕವು ವಿಶಿಷ್ಟವಾಗಿದೆ ಮತ್ತು ವಿಶೇಷ ಗಮನದ ಅಗತ್ಯವಿದ್ದರೆ, ಹೊಂದಿಕೊಳ್ಳುವ ವಿಧಾನಗಳಲ್ಲಿ ಇದು ಈಗಾಗಲೇ ಪ್ರಮಾಣಿತ "ಭಾಗಗಳ" ಗುಂಪಾಗಿದೆ. ಒಂದೆಡೆ, ಹೆಚ್ಚಿನ ಕೋಷ್ಟಕಗಳು ಇವೆ, ಮತ್ತು ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡುವ ಮತ್ತು ಮರುಪಡೆಯುವ ಪ್ರಕ್ರಿಯೆಗಳು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿ ಕಾಣಬೇಕು. ಮತ್ತೊಂದೆಡೆ, ಅವರು ಆಗುತ್ತಾರೆ ವಿಶಿಷ್ಟ. ಅಂದರೆ ಇರಬಹುದು ಸ್ವಯಂಚಾಲಿತ ಮತ್ತು ಮೆಟಾಡೇಟಾ ಚಾಲಿತ. “ನಾವು ಅದನ್ನು ಹೇಗೆ ಇಡುತ್ತೇವೆ?” ಎಂಬ ಪ್ರಶ್ನೆ, ಸುಧಾರಣೆಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವ ಕೆಲಸದ ಮಹತ್ವದ ಭಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದಾದ ಉತ್ತರವು ಈಗ ಅದು ಯೋಗ್ಯವಾಗಿಲ್ಲ (ಹಾಗೆಯೇ ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿ ಮಾದರಿಯನ್ನು ಬದಲಾಯಿಸುವ ಪರಿಣಾಮದ ಬಗ್ಗೆ ಪ್ರಶ್ನೆ. )
ಅಂತಹ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ವಿಶ್ಲೇಷಕರು ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ - ಯಾರಾದರೂ ಇನ್ನೂ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ ವಸ್ತುಗಳ ಗುಂಪಿನ ಮೂಲಕ ಕೆಲಸ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಎಲ್ಲಿ ಮತ್ತು ಹೇಗೆ ಲೋಡ್ ಮಾಡಬೇಕೆಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಆದರೆ ಕೆಲಸದ ಪ್ರಮಾಣ, ಹಾಗೆಯೇ ದೋಷದ ಸಂಭವನೀಯತೆ ಮತ್ತು ವೆಚ್ಚವು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ವಿಶ್ಲೇಷಣಾ ಹಂತದಲ್ಲಿ ಮತ್ತು ETL ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ, ಇದು ಗಮನಾರ್ಹ ಭಾಗದಲ್ಲಿ ಮೆಟಾಡೇಟಾವನ್ನು ಸಂಪಾದಿಸಲು ಕಡಿಮೆ ಮಾಡಬಹುದು.
ಡಾರ್ಕ್ ಸೈಡ್
ಮೇಲಿನ ಎಲ್ಲಾ ಎರಡೂ ವಿಧಾನಗಳನ್ನು ನಿಜವಾಗಿಯೂ ಹೊಂದಿಕೊಳ್ಳುವ, ತಾಂತ್ರಿಕವಾಗಿ ಮುಂದುವರಿದ ಮತ್ತು ಪುನರಾವರ್ತಿತ ಸುಧಾರಣೆಗೆ ಸೂಕ್ತವಾಗಿದೆ. ಸಹಜವಾಗಿ, "ಮುಲಾಮುದಲ್ಲಿ ಬ್ಯಾರೆಲ್" ಸಹ ಇದೆ, ಅದರ ಬಗ್ಗೆ ನೀವು ಈಗಾಗಲೇ ಊಹಿಸಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ಹೊಂದಿಕೊಳ್ಳುವ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳ ಮಾಡ್ಯುಲಾರಿಟಿಗೆ ಆಧಾರವಾಗಿರುವ ಡೇಟಾ ವಿಭಜನೆಯು ಕೋಷ್ಟಕಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಓವರ್ಹೆಡ್ ಮಾದರಿ ಮಾಡುವಾಗ ಸೇರಲು. ಆಯಾಮದ ಎಲ್ಲಾ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸರಳವಾಗಿ ಪಡೆಯಲು, ಕ್ಲಾಸಿಕ್ ಅಂಗಡಿಯಲ್ಲಿ ಒಂದು ಆಯ್ಕೆಮಾಡಿದರೆ ಸಾಕು, ಆದರೆ ಹೊಂದಿಕೊಳ್ಳುವ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಸಂಪೂರ್ಣ ಸರಣಿಯ ಜೋಡಣೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ. ಮೇಲಾಗಿ, ಇವೆಲ್ಲವೂ ವರದಿಗಳಿಗಾಗಿ ಸೇರಿಕೊಳ್ಳುವುದನ್ನು ಮುಂಚಿತವಾಗಿ ಬರೆಯಬಹುದಾದರೆ, SQL ಅನ್ನು ಕೈಯಿಂದ ಬರೆಯಲು ಒಗ್ಗಿಕೊಂಡಿರುವ ವಿಶ್ಲೇಷಕರು ದುಪ್ಪಟ್ಟು ಅನುಭವಿಸುತ್ತಾರೆ.
ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಸುಲಭಗೊಳಿಸುವ ಹಲವಾರು ಸಂಗತಿಗಳಿವೆ:
ದೊಡ್ಡ ಆಯಾಮಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಅದರ ಎಲ್ಲಾ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಬಹುತೇಕ ಏಕಕಾಲದಲ್ಲಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ. ಇದರರ್ಥ ಮಾದರಿಯಲ್ಲಿ ಮೊದಲ ನೋಟದಲ್ಲಿ ತೋರುವುದಕ್ಕಿಂತ ಕಡಿಮೆ ಸೇರ್ಪಡೆಗಳು ಇರಬಹುದು. ಉಪಗ್ರಹಗಳಿಗೆ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹಂಚುವಾಗ ಡೇಟಾ ವಾಲ್ಟ್ ಹಂಚಿಕೆಯ ನಿರೀಕ್ಷಿತ ಆವರ್ತನವನ್ನು ಸಹ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಲೋಡಿಂಗ್ ಹಂತದಲ್ಲಿ ಸರೊಗೇಟ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ಮತ್ತು ಮ್ಯಾಪಿಂಗ್ ಮಾಡಲು ಹಬ್‌ಗಳು ಅಥವಾ ಆಂಕರ್‌ಗಳು ಸ್ವತಃ ಅಗತ್ಯವಿದೆ ಮತ್ತು ಪ್ರಶ್ನೆಗಳಲ್ಲಿ ವಿರಳವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ (ಇದು ಆಂಕರ್‌ಗಳಿಗೆ ವಿಶೇಷವಾಗಿ ಸತ್ಯವಾಗಿದೆ).
ಎಲ್ಲಾ ಸೇರ್ಪಡೆಗಳು ಕೀಲಿಯಿಂದ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಹೆಚ್ಚು “ಸಂಕುಚಿತ” ಮಾರ್ಗವು ಅಗತ್ಯವಿರುವಲ್ಲಿ ಸ್ಕ್ಯಾನಿಂಗ್ ಕೋಷ್ಟಕಗಳ ಓವರ್ಹೆಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಗುಣಲಕ್ಷಣ ಮೌಲ್ಯದಿಂದ ಫಿಲ್ಟರ್ ಮಾಡುವಾಗ). ಪ್ರತಿ ಸಾಲಿಗೆ ಹಲವು ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ಒಂದು ಭಾರೀ ಆಯಾಮವನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವುದಕ್ಕಿಂತಲೂ ಒಂದು ಗುಂಪನ್ನು ಸೇರಿಕೊಳ್ಳುವ ಮೂಲಕ ಸಾಮಾನ್ಯೀಕರಿಸಿದ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಮಾದರಿಯು ವೇಗವಾಗಿರುತ್ತದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಇದು ಕಾರಣವಾಗಬಹುದು.
ಉದಾಹರಣೆಗೆ, ಇಲ್ಲಿ ಲೇಖನವು ಒಂದು ಕೋಷ್ಟಕದಿಂದ ಮಾದರಿಯೊಂದಿಗೆ ಆಂಕರ್ ಮಾದರಿಯ ಕಾರ್ಯಕ್ಷಮತೆಯ ವಿವರವಾದ ತುಲನಾತ್ಮಕ ಪರೀಕ್ಷೆಯನ್ನು ಒಳಗೊಂಡಿದೆ.
ಬಹಳಷ್ಟು ಎಂಜಿನ್ ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಅನೇಕ ಆಧುನಿಕ ವೇದಿಕೆಗಳು ಆಂತರಿಕ ಸೇರ್ಪಡೆ ಆಪ್ಟಿಮೈಸೇಶನ್ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಹೊಂದಿವೆ. ಉದಾಹರಣೆಗೆ, MS SQL ಮತ್ತು Oracle ತಮ್ಮ ಡೇಟಾವನ್ನು ಇತರ ಸೇರ್ಪಡೆಗಳನ್ನು ಹೊರತುಪಡಿಸಿ ಎಲ್ಲಿಯೂ ಬಳಸದಿದ್ದಲ್ಲಿ ಮತ್ತು ಅಂತಿಮ ಆಯ್ಕೆ (ಟೇಬಲ್/ಸೇರುವಿಕೆ ಎಲಿಮಿನೇಷನ್) ಮತ್ತು MPP ವರ್ಟಿಕಾದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದಿದ್ದರೆ ಕೋಷ್ಟಕಗಳಿಗೆ "ಸ್ಕಿಪ್" ಮಾಡಬಹುದು. , ಆಂಕರ್ ಮಾದರಿಗೆ ಅತ್ಯುತ್ತಮ ಎಂಜಿನ್ ಎಂದು ಸಾಬೀತಾಗಿದೆ, ಪ್ರಶ್ನೆ ಯೋಜನೆಯ ಕೆಲವು ಹಸ್ತಚಾಲಿತ ಆಪ್ಟಿಮೈಸೇಶನ್ ನೀಡಲಾಗಿದೆ. ಮತ್ತೊಂದೆಡೆ, ಆಂಕರ್ ಮಾಡೆಲ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುವುದು, ಉದಾಹರಣೆಗೆ, ಕ್ಲಿಕ್ ಹೌಸ್‌ನಲ್ಲಿ, ಇದು ಸೀಮಿತ ಸೇರ್ಪಡೆ ಬೆಂಬಲವನ್ನು ಹೊಂದಿದೆ, ಇದು ಇನ್ನೂ ಉತ್ತಮ ಆಲೋಚನೆಯಂತೆ ಕಾಣುತ್ತಿಲ್ಲ.
ಜೊತೆಗೆ, ಎರಡೂ ವಾಸ್ತುಶಿಲ್ಪಗಳಿಗೆ ಇವೆ ವಿಶೇಷ ಚಲನೆಗಳು, ಡೇಟಾ ಪ್ರವೇಶವನ್ನು ಸುಲಭಗೊಳಿಸುವುದು (ಪ್ರಶ್ನೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ ಮತ್ತು ಅಂತಿಮ ಬಳಕೆದಾರರಿಗಾಗಿ). ಉದಾಹರಣೆಗೆ, ಪಾಯಿಂಟ್-ಇನ್-ಟೈಮ್ ಕೋಷ್ಟಕಗಳು ಡೇಟಾ ವಾಲ್ಟ್‌ನಲ್ಲಿ ಅಥವಾ ವಿಶೇಷ ಟೇಬಲ್ ಕಾರ್ಯಗಳು ಆಂಕರ್ ಮಾದರಿಯಲ್ಲಿ.
ಒಟ್ಟು
ಪರಿಗಣಿಸಲಾದ ಹೊಂದಿಕೊಳ್ಳುವ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳ ಮುಖ್ಯ ಸಾರವೆಂದರೆ ಅವುಗಳ "ವಿನ್ಯಾಸ" ದ ಮಾಡ್ಯುಲಾರಿಟಿ.
ಇದು ಅನುಮತಿಸುವ ಈ ಆಸ್ತಿಯಾಗಿದೆ:
- ಮೆಟಾಡೇಟಾ ನಿಯೋಜನೆ ಮತ್ತು ಮೂಲ ETL ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಬರೆಯುವುದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಕೆಲವು ಆರಂಭಿಕ ತಯಾರಿಯ ನಂತರ, ಮೊದಲ ಫಲಿತಾಂಶವನ್ನು ಗ್ರಾಹಕರಿಗೆ ತ್ವರಿತವಾಗಿ ಒದಗಿಸಿ ಕೆಲವು ಮೂಲ ವಸ್ತುಗಳಿಂದ ಡೇಟಾವನ್ನು ಹೊಂದಿರುವ ಒಂದೆರಡು ವರದಿಗಳ ರೂಪದಲ್ಲಿ. ಸಂಪೂರ್ಣ ವಸ್ತು ಮಾದರಿಯ ಮೂಲಕ (ಮೇಲ್ಮಟ್ಟದಲ್ಲಿಯೂ ಸಹ) ಸಂಪೂರ್ಣವಾಗಿ ಯೋಚಿಸುವುದು ಅನಿವಾರ್ಯವಲ್ಲ.
- ಡೇಟಾ ಮಾದರಿಯು ಕೇವಲ 2-3 ವಸ್ತುಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಬಹುದು (ಮತ್ತು ಉಪಯುಕ್ತವಾಗಬಹುದು). ಕ್ರಮೇಣ ಬೆಳೆಯುತ್ತವೆ (ಆಂಕರ್ ಮಾದರಿ ನಿಕೋಲಾಯ್ ಬಗ್ಗೆ ಕವಕಜಾಲದೊಂದಿಗೆ ಉತ್ತಮ ಹೋಲಿಕೆ).
- ವಿಷಯದ ಪ್ರದೇಶವನ್ನು ವಿಸ್ತರಿಸುವುದು ಮತ್ತು ಹೊಸ ಮೂಲಗಳನ್ನು ಸೇರಿಸುವುದು ಸೇರಿದಂತೆ ಹೆಚ್ಚಿನ ಸುಧಾರಣೆಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ ಮತ್ತು ಈಗಾಗಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಯಾವುದನ್ನಾದರೂ ಮುರಿಯುವ ಅಪಾಯವನ್ನು ಉಂಟುಮಾಡುವುದಿಲ್ಲ.
- ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಅಂಶಗಳಾಗಿ ವಿಭಜನೆಗೆ ಧನ್ಯವಾದಗಳು, ಅಂತಹ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಇಟಿಎಲ್ ಪ್ರಕ್ರಿಯೆಗಳು ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಅವುಗಳ ಬರವಣಿಗೆಯು ಅಲ್ಗಾರಿದಮೈಸೇಶನ್ ಮತ್ತು ಅಂತಿಮವಾಗಿ, ಸ್ವಯಂಚಾಲಿತ.
ಈ ನಮ್ಯತೆಯ ಬೆಲೆ ಕಾರ್ಯಕ್ಷಮತೆ. ಅಂತಹ ಮಾದರಿಗಳಲ್ಲಿ ಸ್ವೀಕಾರಾರ್ಹ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸುವುದು ಅಸಾಧ್ಯವೆಂದು ಇದರ ಅರ್ಥವಲ್ಲ. ಹೆಚ್ಚಾಗಿ, ನೀವು ಬಯಸಿದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಾಧಿಸಲು ನಿಮಗೆ ಹೆಚ್ಚು ಪ್ರಯತ್ನ ಮತ್ತು ವಿವರಗಳಿಗೆ ಗಮನ ಬೇಕಾಗಬಹುದು.
ಅಪ್ಲಿಕೇಶನ್ಗಳು
ಅಸ್ತಿತ್ವದ ವಿಧಗಳು ಡೇಟಾ ವಾಲ್ಟ್
ಡೇಟಾ ವಾಲ್ಟ್ ಕುರಿತು ಹೆಚ್ಚಿನ ಮಾಹಿತಿ:
ಅಸ್ತಿತ್ವದ ವಿಧಗಳು ಆಂಕರ್ ಮಾದರಿ
ಆಂಕರ್ ಮಾದರಿಯ ಕುರಿತು ಹೆಚ್ಚಿನ ವಿವರಗಳು:
ಪರಿಗಣಿಸಲಾದ ವಿಧಾನಗಳ ಸಾಮಾನ್ಯ ಲಕ್ಷಣಗಳು ಮತ್ತು ವ್ಯತ್ಯಾಸಗಳೊಂದಿಗೆ ಸಾರಾಂಶ ಕೋಷ್ಟಕ:
ಮೂಲ: www.habr.com