این مقاله بر روی معماری انبار داده تمرکز دارد. هنگام ساختن آن، چه رویکردهایی باید به کار هدایت شوند - و چرا.

"داستان دروغ است - اما اشاره ای در آن وجود دارد ..."

پدربزرگ کاشته ... انبار. و انبار بزرگ شده است، عالی، عالی. من واقعاً نمی دانستم چگونه کار می کند. و پدربزرگ شروع به بررسی کرد. پدربزرگ مادربزرگ، نوه، گربه و موش را به شورای خانواده فراخواند. و او چنین می گوید: «ذخیره ما بزرگ شده است. داده ها از همه سیستم ها به پایین جریان می یابد، جداول قابل مشاهده و نامرئی هستند. کاربران گزارش های خود را جعل می کنند. به نظر می رسد همه چیز خوب است - زندگی و زندگی کردن. بله، فقط یک غم - هیچ کس نمی داند چگونه کار می کند. به دیسک‌هایی که ظاهراً نامرئی نیاز دارند - نمی‌توانید به اندازه کافی ذخیره کنید! و سپس کاربران عادت کردند با شکایات مختلف به من مراجعه کنند: یا گزارش مسدود می شود یا داده ها قدیمی است. و سپس این یک فاجعه است - ما با گزارش هایی به پدر تزار می آییم ، اما اعداد با یکدیگر موافق نیستند. ساعت هم نیست - پادشاه عصبانی است - پس سر را بر ندار - نه برای من و نه برای تو. بنابراین تصمیم گرفتم شما را دور هم جمع کنم و با هم مشورت کنیم: چه کنیم؟

نگاهش را به جلسه انداخت و پرسید:
- تو، مادربزرگ، می دانی انبار ما چگونه چیده شده است؟
- نه پدربزرگ، نمی دانم. و چگونه می توانم بدانم؟ اونجا، چه پسران شجاعی از او محافظت می کنند! برخی از آنها! نزدیک نخواهی شد. یه جوری به دیدنشون رفتم، کیک پخته بودم. و پای ها را خوردند، سبیل هایشان را پاک کردند و گفتند: «مامان بزرگ چرا آمدی؟ شما چه نوع ذخیره سازی هستید؟ شما به من بگویید چه نوع گزارشی نیاز دارید - ما آن را برای شما انجام خواهیم داد! شما باید پای ها را بیشتر بیاورید! به طرز دردناکی، آنها خوشمزه هستند."
- و شما، نوه محبوب، آیا می دانید انبار ما چگونه تنظیم شده است؟
- نه بابابزرگ، نمی دانم. یک جوری به من دسترسی دادند. من وصل شدم، نگاه می کنم - و جداول وجود دارد - ظاهراً نامرئی است. و طرح های مختلف پنهان می شوند. چشم ها بالا می روند…. اولش گیج شدم. و سپس با دقت نگاه کردم - برخی از آنها خالی هستند، برخی دیگر پر هستند، اما فقط نیمی از آنها. و به نظر می رسد داده ها تکرار می شوند. جای تعجب نیست که با چنین افزونگی، دیسک کافی نخواهید داشت!
- خوب، گربه، در مورد انبار ما چه می گویید؟ آیا چیز خوبی در مورد آن وجود دارد؟
- بله، چگونه نمی گویم، پدربزرگ - من. به درخواست نوه ام، سعی کردم یک خلبان در یک مدار جداگانه - یک ویترین کوچک - بسازم. برای اینکه بفهمیم چه نوع تجارتی برای دولت ما سودآور است - چه محصولاتی برای بازرگانان خوب است ، آنها خراج می دهند - خزانه را پر می کنند. و کدام یک بسیار بد هستند. و من شروع به انتخاب داده برای خودم از این مخزن کردم. حقایق جمع آوری شده و او شروع به مقایسه آنها با محصولات کرد. و چه پدربزرگ، من دیدم - محصولات به نظر یکسان هستند، اما شما به بشقاب ها نگاه می کنید - آنها متفاوت هستند! سپس با شانه نوه ام شروع به شانه زدن آنها کردم. چسال خراشیده شد - و منجر به یکنواختی خاصی شد و چشم ها را نوازش کرد. اما اوایل خوشحال شدم - روز بعد اسکریپت هایم را برای به روز رسانی داده های فوق العاده در پنجره راه اندازی کردم - و همه چیز برای من از بین رفت! "چطور؟" - فکر می کنم - نوه ناراحت می شود - امروز لازم است خلبان خود را به وزیر نشان دهیم. چگونه با چنین داده هایی پیش برویم؟
- آره، قصه های غمگین، گربه، تو بگو. خوب، شما، موش کوچولو، واقعاً سعی نکردید در مورد فضای ذخیره سازی اطلاعات پیدا کنید؟ شما با ما یک دختر سرزنده، چابک، اجتماعی هستید! به ما چه خواهید گفت؟
- بله، چطور، پدربزرگ، سعی نکنید - البته، من یک موش آرام هستم، بله زیرک. یک بار نوه گربه از من خواست تا مدل داده ذخیره سازی ایالت ما را دریافت کنم. و گربه، البته، به سراغ من آمد - برای تو، او می گوید، موش، همه امید! خوب، چه کار خوبی است که افراد خوب (و گربه ها) انجام ندهند؟ به قلعه رفتم، جایی که رئیس انبار مدل داده را در گاوصندوق پنهان می کند. و او پنهان شد. منتظر ماندم تا آن مدل را از گاوصندوق بیرون بیاورد. به محض اینکه برای قهوه رفت بیرون پریدم روی میز. به مدل نگاه می کنم - چیزی نمی فهمم! چطور؟ من فضای ذخیره سازی ما را نمی شناسم! ما هزاران جداول بی‌شماری داریم، جریان‌های داده غیرقابل مهار هستند! و اینجا - همه چیز هماهنگ و زیبا است ... او به همین مدل نگاه کرد - و آن را دوباره در گاوصندوق گذاشت.
- آره، چیزهای خیلی عجیبی به ما گفتی موش.
پدربزرگ سخت فکر کرد.
-دوستان چیکار کنیم؟ از این گذشته، با چنین و فلان مخزن عمر زیادی نخواهید داشت ... کاربران به زودی صبر خود را از دست خواهند داد.

هر چه پدربزرگ ما از یک افسانه تصمیم گرفت - برای ساختن یک انبار جدید یا تلاش برای احیای یک موجود - قبل از "آستین های خود را دوباره بالا بزنیم" لازم است نتیجه گیری کنیم.
بیایید جنبه های سازمانی را کنار بگذاریم - مانند خطر تمرکز تخصص در یک گروه بسته خاص، عدم وجود فرآیندهای کنترلی و اطمینان از شفافیت معماری سیستم های مورد استفاده در سازمان و غیره.
امروز می خواهم روی ساختن معماری یک سیستم خاص (یا گروهی از سیستم ها) تمرکز کنم - انبارهای داده. هنگامی که یک سازمان شروع به ساختن چنین سیستم پیچیده و گران قیمتی به عنوان یک انبار می کند، قبل از هر چیز باید به چه چیزی توجه شود.

تشریح

هیچ یک از ما که روی ایجاد و توسعه هیچ سیستمی کار می کنیم، نمی خواهیم این یک "خانه موقت" یا راه حلی باشد که در یک یا دو سال "پژمرده" شود، زیرا نمی تواند نیازها و انتظارات مشتریان و کسب و کار را برآورده کند. مهم نیست که امروز چقدر تعصب نسبت به «روش‌های انعطاف‌پذیر» مشاهده می‌شود، برای فردی بسیار خوشایندتر است که احساس کند مانند یک «استاد» ویولن می‌سازد تا صنعتگری که چوب‌هایی را برای طبل‌های یکبار مصرف می‌سازد.
قصد ما طبیعی به نظر می‌رسد: ساختن سیستم‌هایی محکم و باکیفیت، که نیازی به داشتن "نظارت شبانه با فایل" به طور منظم نداشته باشند، که برای آن در مقابل کاربران نهایی شرمنده نشویم و شبیه به آن نباشیم. یک "جعبه سیاه" برای همه دنبال کنندگان "ناآشنا".

برای شروع، بیایید لیستی از مشکلات معمولی را که به طور مرتب هنگام کار با مخازن با آنها مواجه می شویم، بیاوریم. بیایید فقط آنچه را که داریم بنویسیم - تا کنون بدون تلاش برای ساده سازی و رسمی کردن.

1. در اصل، ما یک ذخیره سازی خوب داریم: اگر آن را به حال خود رها کنید، همه چیز کار می کند. درست است، به محض نیاز به تغییر، "فروپاشی های محلی" آغاز می شود.
2. داده ها روزانه، طبق مقررات، در یک فرآیند بزرگ، در عرض 8 ساعت آپلود می شوند. و برای ما مناسب است. اما اگر به طور ناگهانی خرابی رخ دهد، نیاز به مداخله دستی دارد. و سپس همه چیز می تواند برای مدت طولانی غیرقابل پیش بینی کار کند، tk. مستلزم مشارکت انسانی در این فرآیند خواهد بود.
3. نسخه را جمع کرده اید - منتظر مشکلات باشید.
4. برخی از منابع نمی توانند داده ها را به موقع ارسال کنند - همه فرآیندها در انتظار هستند.
5. یکپارچگی داده ها توسط پایگاه داده کنترل می شود - بنابراین فرآیندهای ما وقتی خراب می شوند از کار می افتند.
6. ما یک فضای ذخیره سازی بسیار بزرگ داریم - 2000 جدول در یک طرح مشترک. و 3000 مورد دیگر در بسیاری از طرح های دیگر. ما قبلاً تصور کمی از نحوه چیدمان آنها و به چه دلیل ظاهر شده اند. بنابراین، ممکن است استفاده مجدد از چیزی برای ما دشوار باشد. و بسیاری از کارها باید دوباره حل شوند. زیرا، این آسان تر و سریعتر است (از درک "کد شخص دیگری"). در نتیجه، مغایرت‌ها و عملکردهای تکراری داریم.
7. ما انتظار داریم منبع داده های با کیفیت خوب ارائه دهد. اما معلوم شد که اینطور نیست. در نتیجه، ما زمان زیادی را صرف تطبیق گزارش های نهایی خود می کنیم. و در این امر بسیار موفق بودند. ما حتی یک فرآیند ساده داریم. درست است، زمان می برد. اما کاربران عادت کرده اند ...
8. کاربر همیشه به گزارش های ما اعتماد ندارد و نیاز به توجیه یک یا آن رقم دارد. در برخی موارد حق با اوست و در برخی دیگر نه. اما توجیه آنها برای ما بسیار دشوار است، زیرا ما هیچ وسیله ای برای "تحلیل انتها به انتها" (یا اصل و نسب داده) نداریم.
9. ما می توانیم توسعه دهندگان بیشتری بیاوریم. اما ما یک مشکل داریم - چگونه آنها را در کار قرار دهیم؟ کارآمدترین راه برای موازی سازی مشاغل چیست؟
10. چگونه می توان به تدریج سیستم را توسعه داد، بدون اینکه یک سال تمام به توسعه "هسته سیستم" بپردازیم؟
11. انبار داده با مدل شرکتی مرتبط است. اما ما مطمئناً می دانیم (این را در بانک XYZ دیدیم) که ساخت یک مدل می تواند بی نهایت طولانی باشد (ما به مدت شش ماه به بانک XYZ رفتیم و در مورد نهادهای تجاری بحث کردیم، بدون هیچ حرکتی). اصلا چرا اوست؟ یا شاید بدون او بهتر است، اگر مشکلات زیادی با او وجود دارد؟ شاید بتوانیم به نحوی آن را تولید کنیم؟
12. ما تصمیم گرفتیم مدل را رانندگی کنیم. اما چگونه می توان مدل داده های انبار را به طور سیستماتیک تکامل داد؟ آیا ما به "قوانین بازی" نیاز داریم و آنها چه می توانند باشند؟ چه چیزی به ما خواهد داد؟ اگر با مدل اشتباه کنیم چه؟
13. اگر «کسب و کار به آن نیاز ندارد»، باید داده ها یا تاریخچه تغییرات آن را ذخیره کنیم؟ من نمی خواهم "زباله" را ذخیره کنم و استفاده از این داده ها را برای کارهای واقعی پیچیده کنم. آیا طاق باید تاریخ را حفظ کند؟ چگونه است؟ ذخیره سازی در طول زمان چگونه کار می کند؟
14. اگر یک سیستم مدیریت داده اصلی داریم، آیا باید سعی کنیم داده ها را در فضای ذخیره سازی یکسان کنیم؟ اگر MDM هست یعنی الان کل مشکل اصلی دیتا حل شده؟
15. انتظار می رود به زودی سیستم های کلیدی حسابداری را جایگزین کنیم. آیا دیتا استور برای تغییر منبع باید آماده باشد؟ چگونه می توان به این امر دست یافت؟
16. آیا ما به ابرداده نیاز داریم؟ منظور ما از این چیست؟ دقیقا کجا میشه ازشون استفاده کرد؟ چگونه می توانید آن را پیاده سازی کنید؟ آیا باید آنها را "در یک مکان" ذخیره کنم؟
17. مشتریان ما در الزامات و خواسته های خود بسیار ناپایدار هستند - چیزی به طور مداوم در حال تغییر است. به طور کلی، کسب و کار ما بسیار پویا است. در حالی که ما در حال انجام کاری هستیم، از قبل غیر ضروری می شود. چگونه می توانیم این کار را به گونه ای انجام دهیم که نتیجه را در سریع ترین زمان ممکن به دست آوریم - مانند کیک داغ؟
18. کاربران خواستار پاسخگویی هستند. اما ما نمی توانیم فرآیندهای بوت اصلی خود را اغلب اجرا کنیم، زیرا این سیستم‌های منبع را بارگیری می‌کند (اثر بدی بر عملکرد دارد) - بنابراین، جریان‌های داده اضافی را قطع می‌کنیم - که به صورت نقطه‌ای انتخاب می‌کنند - آنچه ما نیاز داریم. درست است، جریان های زیادی وجود دارد. و سپس برخی از داده ها را دور می اندازیم. علاوه بر این، مشکل همگرایی وجود خواهد داشت. اما راه دیگری نیست...

قبلاً خیلی چیزها اتفاق افتاده است. اما این یک لیست کامل نیست - تکمیل و توسعه آن آسان است. ما آن را در جدول پنهان نمی کنیم، بلکه آن را در مکانی آشکار آویزان می کنیم - این مسائل را در کانون توجه خود در روند کار قرار دهید.
وظیفه ما این است که در نتیجه به یک راه حل جامع برسیم.

ضد شکنندگی

با نگاهی به لیست ما، می توان یک نتیجه گرفت. ایجاد نوعی «پایگاه داده برای گزارش‌دهی»، آپلود داده‌ها در آنجا، یا حتی ایجاد نوعی فرآیند به‌روزرسانی معمول داده‌ها دشوار نیست. سیستم به نوعی شروع به زندگی می کند ، کاربران ظاهر می شوند و با آنها تعهدات و SLA ، الزامات جدید ایجاد می شود ، منابع اضافی متصل می شوند ، روش ها تغییر می کنند - همه اینها باید در فرآیند توسعه در نظر گرفته شود.

پس از مدتی، تصویر به شرح زیر است:
«اینجا طاق است. و اگر به آن دست نزنید کار می کند. مشکلات زمانی به وجود می آیند که باید چیزی را تغییر دهیم."

تغییری به ما می رسد که نمی توانیم تأثیر آن را ارزیابی و درک کنیم (چون از همان ابتدا چنین ابزارهایی را در سیستم قرار نداده ایم) - و برای اینکه ریسک نکنیم به آنچه هست دست نمی زنیم. اما ما یک توسعه دیگر را در کنار انجام می دهیم، و دیگری، و همچنین - تصمیم خود را به محله های فقیر نشین، یا، همانطور که در آمریکای لاتین می گویند، "فاولا" تبدیل می کنیم، جایی که حتی پلیس از ورود به آن می ترسد.
احساس از دست دادن کنترل بر سیستم خود، هرج و مرج وجود دارد. برای حفظ فرآیندهای موجود و حل مشکلات، دست های بیشتری لازم است. و ایجاد تغییرات سخت تر و سخت تر می شود. به عبارت دیگر، سیستم در برابر استرس ناپایدار و با تغییرات ناسازگار می شود. و علاوه بر این، وابستگی شدیدی به شخصیت‌هایی وجود دارد که «راه را می‌شناسند»، زیرا هیچ‌کس «نقشه» ندارد.

نسیم نیکلاس طالب این خاصیت یک شی را - فروپاشی تحت تأثیر هرج و مرج، حوادث تصادفی و شوک ها می نامد. تردی ... و همچنین مفهوم مخالف را معرفی می کند: ضد شکنندگی – زمانی که جسم در اثر استرس و حوادث فرو نمی ریزد، بلکه مستقیماً از آن سود می برد... ("ضد شکنندگی. چگونه از هرج و مرج بهره مند شویم")
در غیر این صورت می توان آن را نامید تطبیق پذیری یا انعطاف پذیری در برابر تغییر .

این در این زمینه به چه معناست؟ "منابع آشوب" برای سیستم های IT چیست؟ و از نظر معماری فناوری اطلاعات "سرمایه گذاری بر هرج و مرج" به چه معناست؟
اولین فکری که به ذهن می رسد تغییراتی است که از بیرون می آید. دنیای بیرون برای نظام چیست؟ مخصوصا برای ذخیره سازی البته، اول از همه - تغییرات از طرف منابع داده برای فروشگاه:

• تغییر فرمت داده های دریافتی؛
• جایگزینی برخی از سیستم های منبع داده با سایرین؛
• تغییر قوانین / پلت فرم برای یکپارچه سازی سیستم ها؛
• تغییر تفسیر داده ها (فرمت ها ذخیره می شوند، منطق کار با داده ها تغییر می کند).
• اگر ادغام در سطح داده انجام شود، مدل داده را تغییر دهید (تجزیه فایل های گزارش تراکنش پایگاه داده).
• رشد حجم داده ها - در حالی که داده های زیادی در سیستم منبع وجود نداشت، و بار زیاد نبود - امکان بازیابی آن در هر زمان وجود داشت، با درخواست خودسرانه سنگین، داده ها و بار افزایش یافت - اکنون محدودیت های سختی وجود دارد. ;
• و غیره.

خود سیستم های منبع، ترکیب اطلاعات و ساختار آن، نوع تعامل یکپارچه سازی و همچنین منطق کار با داده ها می تواند تغییر کند. هر سیستمی مدل داده و رویکردهای خود را برای کار با آنها پیاده سازی می کند که اهداف و مقاصد سیستم را برآورده می کند. و مهم نیست که چقدر تلاش می کنند تا مدل های صنعتی و شیوه های مرجع را متحد کنند، ناگزیر تفاوت های ظریف ظاهر می شود. (و علاوه بر این، خود فرآیند یکسان سازی صنعت به دلایل مختلف پیشرفت چندانی ندارد.)
فرهنگ کار با داده های شرکتی - حضور و کنترل معماری اطلاعات، یک مدل معنایی یکپارچه، سیستم های مدیریت داده های اصلی (MDM) تا حدودی کار تلفیق داده ها را در انبار تسهیل می کند، اما نیاز آن را رد نمی کند.

تغییرات کمتر بحرانی توسط مصرف کنندگان انبار آغاز نمی شود (تغییر الزامات):

• قبلاً داده های کافی برای ایجاد یک گزارش وجود داشت - اکنون باید فیلدهای اضافی یا یک منبع داده جدید را متصل کنید.
• تکنیک‌های پردازش داده‌ای که قبلاً اجرا شده‌اند منسوخ شده‌اند - باید الگوریتم‌ها و هر چیزی را که بر آن تأثیر می‌گذارد دوباره کار کنید.
• قبلاً همه از مقدار فعلی ویژگی فرهنگ لغت در پانل اطلاعات راضی بودند - اکنون مقداری لازم است که در زمان واقعیت / رویداد تجزیه و تحلیل شده مرتبط باشد.
• نیاز به عمق تاریخچه ذخیره سازی داده ها وجود داشت که قبلاً وجود نداشت - ذخیره داده ها نه برای 2 سال بلکه برای 10 سال.
• قبلاً داده های کافی تا "پایان روز / دوره" وجود داشت - اکنون به وضعیت داده "در روز" یا در زمان یک رویداد خاص نیاز دارید (مثلاً تصمیم گیری در مورد درخواست وام - برای بازل II)؛
• قبلاً از گزارش داده های دیروز (T-1) یا بعداً راضی بودیم، اکنون به T0 نیاز داریم.
• و غیره.

هم تعاملات یکپارچه سازی با سیستم های منبع و هم نیازهای مصرف کنندگان داده های انبار عوامل خارجی برای انبار داده هستند: برخی از سیستم های منبع جایگزین سایرین می شوند، حجم داده ها رشد می کند، قالب های داده های دریافتی تغییر می کند، نیازهای کاربر تغییر می کند و غیره. و همه اینها تغییرات خارجی معمولی هستند که سیستم ما - مخزن ما - باید برای آنها آماده باشد. با معماری مناسب، آنها نباید سیستم را بکشند.

اما این همه ماجرا نیست.
وقتی در مورد تنوع صحبت می کنیم، اول از همه عوامل خارجی را به یاد می آوریم. از این گذشته ، در درون ما می توانیم همه چیز را کنترل کنیم ، به نظر ما اینطور است ، درست است؟ بله و خیر. بله، بیشتر عواملی که خارج از حوزه نفوذ هستند، خارجی هستند. اما "آنتروپی داخلی" نیز وجود دارد. و دقیقاً به دلیل وجود آن، گاهی اوقات نیاز داریم به "نقطه 0" برگردیم. بازی را دوباره شروع کنید
در زندگی، ما اغلب تمایل داریم که از صفر شروع کنیم. چرا این برای ما عجیب است؟ و آیا واقعا اینقدر بد است؟
در IT اعمال شد. برای خود سیستم - این می تواند بسیار خوب باشد - توانایی تجدید نظر در تصمیمات فردی. به خصوص زمانی که بتوانیم آن را به صورت محلی انجام دهیم. Refactoring فرآیند بازگشایی "وب" است که به طور دوره ای در فرآیند توسعه سیستم ظاهر می شود. بازگشت به ابتدا می تواند مفید باشد. اما قیمتی دارد.
با مدیریت شایسته معماری، این قیمت کاهش می یابد - و فرآیند توسعه سیستم به خودی خود قابل کنترل تر و شفاف تر می شود. یک مثال ساده: اگر اصل مدولار بودن رعایت شود، می‌توانید یک ماژول جداگانه را بدون تأثیر بر رابط‌های خارجی بازنویسی کنید. و این را نمی توان با ساختار یکپارچه انجام داد.

ضد شکنندگی یک سیستم با معماری تعبیه شده در آن تعیین می شود. و همین ویژگی است که آن را تطبیقی ​​می کند.
وقتی صحبت می کنیم معماری تطبیقی- منظور ما این است که سیستم قادر به تطبیق با تغییرات است و اصلاً این نیست که ما دائماً خود معماری را تغییر می دهیم. برعکس، هرچه معماری پایدارتر و پایدارتر باشد، الزامات کمتری که مستلزم تجدیدنظر در آن است، سیستم سازگارتر است.

راه حل هایی که شامل بازنگری در کل معماری هستند قیمت بسیار بالاتری خواهند داشت. و شما باید دلایل بسیار خوبی برای پذیرش آنها داشته باشید. برای مثال، چنین منطقی ممکن است الزامی باشد که در معماری موجود قابل اجرا نباشد. سپس آنها می گویند - یک الزام ظاهر شده است که بر معماری تأثیر می گذارد.
بنابراین، ما همچنین باید "محدودیت های ضد شکنندگی" خود را بدانیم. معماری "در خلاء" توسعه نمی یابد - بر اساس نیازها و انتظارات فعلی است. و اگر وضعیت اساساً تغییر کند - باید درک کنیم که از معماری فعلی فراتر رفته‌ایم - و باید آن را بازنگری کنیم، راه حل متفاوتی پیدا کنیم - و به مسیرهای گذار فکر کنیم.
به عنوان مثال، ما فرض کردیم که همیشه در پایان روز به داده‌هایی در فضای ذخیره‌سازی نیاز داریم، هر روز با استفاده از رابط‌های استاندارد سیستم (از طریق مجموعه‌ای از نماها) داده‌ها را می‌گیریم. سپس از بخش مدیریت ریسک تقاضا برای نیاز به دریافت داده ها نه در پایان روز، بلکه در زمان تصمیم گیری در مورد وام مطرح شد. نیازی به تلاش برای "کشش غیر کششی" نیست - فقط باید این واقعیت را بپذیرید - هر چه زودتر بهتر. و شروع به کار روی رویکردی کنیم که به ما امکان می دهد مشکل را حل کنیم.
در اینجا خط بسیار ظریفی وجود دارد - اگر فقط "الزامات لحظه ای" را در نظر بگیریم و چندین گام به جلو (و چندین سال جلوتر) نگاه نکنیم، در این صورت خطر مواجهه با الزاماتی را افزایش می دهیم که خیلی دیر بر معماری تأثیر می گذارد - و قیمت تغییر ما بسیار بالا خواهد بود. کمی جلوتر نگاه کردن - در محدوده افق ما - هنوز به کسی آسیب نزده است.

نمونه سیستمی از «داستان ذخیره‌سازی» تنها نمونه‌ای از یک سیستم بسیار متزلزل است که بر اساس رویکردهای طراحی شکننده ساخته شده است. و اگر این اتفاق بیفتد، تخریب برای این کلاس خاص از سیستم‌ها بسیار سریع اتفاق می‌افتد.
چرا می توانم اینطور بگویم؟ موضوع مخازن جدید نیست. رویکردها و شیوه های مهندسی که در این مدت توسعه داده شده اند دقیقاً در این هدف بوده اند - حفظ بقای سیستم.
یک مثال ساده: یکی از رایج‌ترین دلایل شکست پروژه‌های ذخیره‌سازی برخاسته، تلاش برای ایجاد فضای ذخیره‌سازی بر روی سیستم‌های منبع توسعه بدون توافق بر سر رابط‌های یکپارچه‌سازی است – تلاش برای واکشی مستقیم داده‌ها از جداول. در نتیجه، ما وارد توسعه شدیم - در این مدت پایگاه داده منبع تغییر کرد - و جریان های بارگذاری در مخزن غیرفعال شدند. برای دوباره کاری خیلی دیر شده است. و اگر هنوز خود را با ساختن چندین لایه میز در داخل انباری ایمن نکرده اید، می توانید همه چیز را بیرون بیندازید و از نو شروع کنید. این فقط یک مثال است و یکی از نمونه های ساده.

معیار طالب برای شکننده بودن و ضد شکننده بودن ساده است. قاضی اصلی زمان است. اگر سیستم در آزمون زمان مقاومت کند و "سرزندگی" و "نابودی" خود را نشان دهد - دارای خاصیت ضد شکنندگی است.
اگر هنگام طراحی یک سیستم، ضد شکنندگی را به عنوان یک الزام در نظر بگیریم، این ما را تشویق می کند تا از چنین رویکردهایی برای ساخت معماری آن استفاده کنیم که سیستم را هم با "آشوب از بیرون" و هم با "آشوب از درون" سازگارتر می کند. . و در نهایت این سیستم طول عمر بیشتری خواهد داشت.
هیچ کدام از ما نمی خواهیم "خانه های موقت" بسازیم. و خود را فریب ندهید که امروز راه دیگری نیست. طبیعی است که انسان در هر زمانی، به خصوص در زمان بحران، چند قدم جلوتر نگاه کند.

انبار داده چیست و چرا آن را می سازیم

مقاله معماری ذخیره‌سازی فرض می‌کند که خواننده نه تنها می‌داند که چیست، بلکه تجربه‌ای با چنین سیستم‌هایی دارد. با این وجود، انجام این کار را ضروری دانستم - بازگشت به مبدا، به ابتدای راه، زیرا آنجاست که نقطه اتکای توسعه قرار دارد.

چگونه مردم به این ایده رسیدند که انبارهای داده مورد نیاز است؟ و چه تفاوتی با یک "پایگاه داده بسیار بزرگ" دارند؟
مدت‌ها پیش، زمانی که به سادگی «سیستم‌های پردازش داده‌های تجاری» در جهان وجود داشت، هیچ تقسیم‌بندی سیستم‌های فناوری اطلاعات به کلاس‌هایی مانند سیستم‌های oltp front-end، dss back-office، سیستم‌های پردازش متن، انبارهای داده و غیره وجود نداشت.
در این زمان بود که اولین موتور پایگاه داده رابطه ای، انگرس، توسط مایکل استون بریکر ایجاد شد.
و آن زمانی بود که عصر کامپیوترهای شخصی مانند گردبادی وارد صنعت کامپیوتر شد و برای همیشه ایده های جامعه فناوری اطلاعات آن زمان را تغییر داد.

در آن زمان یافتن برنامه های کاربردی سازمانی که بر اساس DBMS های کلاس دسکتاپ نوشته شده بودند، مانند Clipper، dBase و FoxPro آسان بود. و بازار برنامه های کاربردی مشتری-سرور و DBMS تنها در حال افزایش بود. سرورهای پایگاه داده یکی پس از دیگری ظاهر شدند که برای مدت طولانی جایگاه خود را در فضای فناوری اطلاعات اشغال می کنند - Oracle ، DB2 و غیره.
و اصطلاح "کاربرد پایگاه داده" رایج بوده است. چنین برنامه ای شامل چه مواردی بود؟ ساده شده - برخی از فرم های ورودی که از طریق آنها کاربران می توانند به طور همزمان اطلاعات را وارد کنند، برخی از محاسباتی که "با دکمه" یا "بر اساس برنامه" راه اندازی شده اند، و همچنین برخی از گزارش هایی که می توانند روی صفحه دیده شوند یا به عنوان فایل ذخیره شده و برای مهر و موم ارسال شوند.
یکی از مربیان من در اوایل کارم گفت: "هیچ چیز خاصی نیست - فقط یک برنامه معمولی، فقط یک پایگاه داده." "پس چیز خاصی نیست؟" - اون موقع فکر کردم

اگر با دقت نگاه کنید، هنوز برخی از ویژگی های خاص وجود دارد. با رشد کاربران، حجم اطلاعات دریافتی افزایش می یابد، با افزایش بار روی سیستم، توسعه دهندگان، طراحان آن، برای حفظ عملکرد در سطح قابل قبول، به سراغ برخی «ترفندها» می روند. اولین مورد، تقسیم یک "سیستم پردازش داده های تجاری" یکپارچه به یک برنامه حسابداری است که کاربران را به صورت آنلاین پشتیبانی می کند و یک برنامه جداگانه برای پردازش دسته ای داده ها و گزارش ها. هر یک از این برنامه ها پایگاه داده خاص خود را دارند و حتی در یک نمونه جداگانه از سرور پایگاه داده با تنظیمات مختلف برای انواع بارگذاری - OLTP و DSS میزبانی می شوند. و جریان های داده بین آنها ردیف می شود.

این همه؟ به نظر می رسد که مشکل حل شده است. بعد چه اتفاقی می افتد؟
و سپس شرکت ها رشد می کنند، نیازهای اطلاعاتی آنها چند برابر می شود. تعداد تعاملات با دنیای خارج نیز رو به افزایش است. و در نتیجه، یک برنامه بزرگ وجود ندارد که تمام فرآیندها را کاملاً خودکار کند، بلکه چندین برنامه مختلف از تولید کنندگان مختلف وجود دارد. تعداد سیستم های تولید کننده اطلاعات - سیستم های منبع داده در شرکت در حال افزایش است. و دیر یا زود نیاز به دیدن و مقایسه اطلاعات دریافتی از سیستم های مختلف خواهد بود. اینگونه است که انبارهای داده در شرکت ظاهر می شوند - کلاس جدیدی از سیستم ها.
تعریف عمومی پذیرفته شده این دسته از سیستم ها به شرح زیر است.

انبار داده (یا انبار داده)- یک پایگاه اطلاعاتی موضوع محور که به طور ویژه برای تهیه گزارش ها و تحلیل های تجاری به منظور حمایت از تصمیم گیری در یک سازمان طراحی و طراحی شده است.

بدین ترتیب، تثبیتداده های سیستم های مختلف، توانایی نگاه کردن به آنها به روش "یکنواخت" (یکپارچه) - این یکی از ویژگی های کلیدی سیستم های کلاس انبارهای داده است. به همین دلیل است که مخازن در طول تکامل سیستم های فناوری اطلاعات پدیدار شده اند.

ویژگی های کلیدی انبارهای داده

بیایید نگاه دقیق تری بیندازیم. ویژگی های کلیدی این سیستم ها چیست؟ چه چیزی انبارهای داده را از سایر سیستم های فناوری اطلاعات سازمانی متمایز می کند؟

اول اینکه اینها حجم زیادی هستند. خیلی بزرگه VLDB - هنگامی که فروشندگان پیشرو توصیه های خود را در مورد استفاده از محصولات خود ارائه می دهند، چنین سیستم هایی را نام می برند. از تمام سیستم های شرکت، داده ها به این پایگاه داده بزرگ سرازیر می شوند و همانطور که در کتاب های درسی می گویند "برای همیشه و بدون تغییر" در آنجا ذخیره می شود (در عمل، زندگی پیچیده تر به نظر می رسد).

دوم، این داده های تاریخی است - "حافظه شرکتی" - به اصطلاح انبارهای داده. از نظر کار با زمان در مخازن، همه چیز بسیار جالب است. در سیستم های حسابداری، داده ها در حال حاضر به روز هستند. سپس کاربر نوعی عملیات را انجام می دهد - و داده ها به روز می شوند. در عین حال، تاریخچه تغییرات ممکن است ذخیره نشود - این به عملکرد حسابداری بستگی دارد. برای مثال موجودی حساب بانکی را در نظر بگیرید. ممکن است به تراز فعلی در «اکنون»، در پایان روز، یا در زمان وقوع رویدادی (مثلاً در زمان محاسبه امتیاز) علاقه مند باشیم. در حالی که حل دو مورد اول نسبتاً آسان است، دومی به احتمال زیاد به تلاش های ویژه ای نیاز دارد. کاربر هنگام کار با ذخیره سازی می تواند به دوره های گذشته مراجعه کرده، آنها را با دوره فعلی مقایسه کند و غیره. این قابلیت های مربوط به زمان است که به طور قابل توجهی انبارهای داده را از سیستم های حسابداری - بدست آوردن وضعیت داده ها در نقاط مختلف محور زمانی - تا عمق معینی در گذشته متمایز می کند.

سوم، این است تثبیت و یکسان سازی داده ها ... برای اینکه تجزیه و تحلیل مشترک آنها ممکن شود، لازم است آنها را به یک شکل مشترک برسانیم - مدل داده یکپارچه ، حقایق را با کتاب های مرجع یکپارچه مقایسه کنید. در اینجا ممکن است چندین جنبه و دشواری وجود داشته باشد. اول از همه - مفهومی - تحت یک اصطلاح، افراد مختلف از بخش های مختلف می توانند چیزهای مختلفی را درک کنند. و بالعکس - چیزی را متفاوت نامید، که اساساً همان چیز است. چگونه می توان "نمای واحد" را با حفظ دید خاص یک گروه کاربری خاص ارائه داد؟

چهارم، این کار با کیفیت داده ... در فرآیند بارگذاری داده ها در ذخیره سازی، آنها تمیز می شوند، تبدیل ها و تبدیل های کلی انجام می شود. تغییرات کلی باید در یک مکان انجام شود - و سپس برای ساخت گزارش های مختلف استفاده شود. این امر از تناقضاتی که کاربران تجاری را آزار می دهد جلوگیری می کند - به ویژه مدیرانی که با شماره هایی از بخش های مختلف که با یکدیگر موافق نیستند کنار میز آورده می شوند. کیفیت پایین داده ها باعث ایجاد خطا و مغایرت در گزارش ها می شود که پیامد آن کاهش سطح است اعتماد کاربر به کل سیستم، به کل سرویس تحلیلی به عنوان یک کل.

مفهوم معماری

هر کسی که با یک مخزن مواجه شده است به احتمال زیاد نوعی "ساختار لایه ای" را مشاهده کرده است - از آنجا که این پارادایم معماری است که برای سیستم های این کلاس ریشه دوانده است. و تصادفی نیست. لایه های ذخیره سازی را می توان به عنوان اجزای جداگانه سیستم - با وظایف خاص خود، حوزه مسئولیت، "قوانین بازی" درک کرد.
معماری لایه ای وسیله ای برای مقابله با پیچیدگی سیستم است - هر سطح بعدی از پیچیدگی های اجرای داخلی قبلی انتزاع می شود. این رویکرد به شما امکان می دهد تا کارهایی از همان نوع را مشخص کنید و آنها را به روشی یکنواخت حل کنید، بدون اینکه هر بار "چرخ" را دوباره از ابتدا اختراع کنید.
نمودار معماری مفهومی به صورت شماتیک در شکل نشان داده شده است. این یک نمودار ساده شده است که فقط ایده کلیدی - مفهوم را منعکس می کند، اما بدون "جزئیات تشریحی" که با توضیح عمیق تر جزئیات ایجاد می شود.

همانطور که در نمودار نشان داده شده است، لایه های زیر را به صورت مفهومی انتخاب کنید. سه لایه اصلی که شامل فضای ذخیره سازی داده ها (که با مستطیل پر شده مشخص می شود) و نرم افزار بارگذاری داده ها (به طور معمول با فلش های همرنگ نشان داده می شود). و همچنین یک لایه خدماتی کمکی، که، با این حال، نقش اتصال بسیار مهمی را ایفا می کند - مدیریت بار داده و کنترل کیفیت.

لایه داده اولیه - لایه داده اولیه (یا صحنه سازی ، یا لایه عامل ) - طراحی شده برای بارگیری از سیستم های منبع و ذخیره اطلاعات اولیه، بدون تغییر - با کیفیت اصلی و پشتیبانی از تاریخچه کامل تغییرات.
وظیفه این لایه- انتزاع لایه های بعدی ذخیره سازی از ساختار فیزیکی منابع داده، روش های جمع آوری داده ها و روش های جداسازی دلتای تغییرات.

لایه داده هسته - ذخیره سازی هسته - جزء مرکزی سیستم که ذخیره سازی را از یک "پلتفرم یکپارچه سازی دسته ای" یا "سطل داده های بزرگ" متمایز می کند، زیرا نقش اصلی آن است. ادغام داده هااز منابع مختلف، کاهش به ساختارهای یکنواخت، کلیدها. هنگام بارگذاری در هسته است که کار اصلی با کیفیت داده و تغییرات کلی انجام می شود که می تواند بسیار پیچیده باشد.
وظیفه این لایه- انتزاع مصرف کنندگان خود از ویژگی های دستگاه منطقی منابع داده و نیاز به مقایسه داده ها از سیستم های مختلف، برای اطمینان از یکپارچگی و کیفیت داده ها.

لایه داده مارت - ویترین های تحلیلی - مؤلفه ای که وظیفه اصلی آن تبدیل داده ها به ساختارهایی است که برای تجزیه و تحلیل مناسب هستند (اگر BI با ویترین کار می کند ، این معمولاً یک مدل بعدی است) یا مطابق با الزامات سیستم مصرف کننده.
به عنوان یک قاعده، data marts داده ها را از هسته - به عنوان یک منبع قابل اعتماد و تأیید شده - می گیرند. از سرویس این مؤلفه برای آوردن داده ها به یک فرم استفاده کنید. ما به این گونه ویترین ها می گوییم منظم ... در برخی موارد، ویترین ها می توانند داده ها را مستقیماً از مرحله بندی دریافت کنند - با داده های اولیه (در کلیدهای منبع) کار می کنند. این رویکرد معمولاً برای کارهای محلی استفاده می شود که در آن ادغام داده ها از سیستم های مختلف مورد نیاز نیست و در جایی که کارایی بیش از کیفیت داده مورد نیاز است. چنین کیس های نمایشی نامیده می شوند عملیاتی ... برخی از شاخص های تحلیلی می توانند روش های محاسباتی بسیار پیچیده ای داشته باشند. بنابراین، برای این گونه محاسبات و تبدیلات غیر پیش پا افتاده، به اصطلاح ویترین های ثانویه .
وظیفه لایه نمایشی- آماده سازی داده ها با توجه به نیازهای یک مصرف کننده خاص - یک پلت فرم BI، گروهی از کاربران یا یک سیستم خارجی.

لایه هایی که در بالا توضیح داده شد شامل یک منطقه ذخیره سازی دائمی داده و همچنین یک ماژول نرم افزاری برای بارگذاری و تبدیل داده ها می باشد. این تقسیم بندی به لایه ها و مناطق منطقی است. از نظر فیزیکی، اجرای این مؤلفه‌ها می‌تواند متفاوت باشد - اگر کارآمدتر باشد، حتی می‌توانید از پلتفرم‌های مختلفی برای ذخیره یا تبدیل داده‌ها در لایه‌های مختلف استفاده کنید.
مناطق ذخیره سازی شامل فنی (جدول بافر) است که در فرآیند تبدیل داده ها و جداول هدفکه جزء مصرف کننده به آن اشاره دارد. تمرین خوبی است که جداول هدف را با نماها "پوشانده شود". این امر نگهداری و توسعه بعدی سیستم را تسهیل می کند. داده‌ها در جداول هدف هر سه لایه با فیلدهای فنی خاص (متا ویژگی‌ها) مشخص می‌شوند که برای پشتیبانی از فرآیندهای بارگذاری داده‌ها و همچنین برای فعال کردن ممیزی اطلاعاتی جریان داده‌ها در انبار استفاده می‌شوند.

همچنین، یک مؤلفه خاص (یا مجموعه ای از مؤلفه ها) متمایز می شود که عملکردهای خدماتی را برای همه لایه ها ارائه می دهد. یکی از وظایف کلیدی آن عملکرد کنترل است - ارائه "قوانین یکنواخت بازی" برای کل سیستم به عنوان یک کل، و حق استفاده از گزینه های مختلف برای اجرای هر یک از لایه های شرح داده شده در بالا - از جمله. از فناوری های مختلف برای بارگیری و پردازش داده ها، بسترهای ذخیره سازی مختلف و غیره استفاده کنید. بیایید آن را صدا کنیم لایه خدماتی ... این شامل داده های تجاری نیست، اما دارای ساختارهای ذخیره سازی خاص خود است - شامل یک منطقه ابرداده، و همچنین منطقه ای برای کار با کیفیت داده ها (و احتمالاً ساختارهای دیگر، بسته به عملکردهایی است که به آن اختصاص داده شده است).

چنین تقسیم واضحی از سیستم به اجزای جداگانه به طور قابل توجهی قابلیت کنترل توسعه سیستم را افزایش می دهد:

• پیچیدگی وظیفه ای که برای توسعه دهنده عملکرد این یا آن مؤلفه قرار می گیرد کاهش می یابد (او نباید همزمان مسائل ادغام با سیستم های خارجی را حل کند و به رویه های پاکسازی داده ها فکر کند و در مورد ارائه بهینه داده ها فکر کند. برای مصرف کنندگان) - تجزیه، ارزیابی و انجام یک تحویل کوچک آسان تر است.
• شما می توانید به کار مجریان مختلف (و حتی تیم ها یا پیمانکاران) متصل شوید - زیرا این رویکرد به شما امکان می دهد وظایف را به طور مؤثر موازی کنید و تأثیر متقابل آنها را بر یکدیگر کاهش دهید.
• وجود مرحله‌بندی مداوم به شما امکان می‌دهد بدون طراحی کل هسته یا ویترین فروشگاه برای کل منطقه موضوع، منابع داده را به سرعت به هم متصل کنید، و سپس به تدریج ساخت لایه‌های باقیمانده را مطابق با اولویت‌ها به پایان برسانید (علاوه بر این، داده‌ها از قبل در ذخیره‌سازی خواهند بود - در دسترس تحلیلگران سیستم، که تا حد زیادی وظایف توسعه بعدی ذخیره سازی را تسهیل می کند.
• وجود یک هسته اجازه می دهد تا تمام کارهای با کیفیت داده (و همچنین اشتباهات و خطاهای احتمالی) از ویترین فروشگاه ها و از کاربر نهایی پنهان شود و مهمتر از همه - با استفاده از این مؤلفه به عنوان یک منبع داده واحد برای ویترین فروشگاه ها، می توانید از داده ها جلوگیری کنید. مشکلات همگرایی به دلیل اجرای الگوریتم های رایج در یک مکان.
• برجسته کردن مارت به شما امکان می دهد تفاوت ها و ویژگی های درک داده هایی را که کاربران بخش های مختلف ممکن است داشته باشند در نظر بگیرید، و طراحی آنها برای الزامات BI نه تنها اجازه می دهد تا ارقام جمع آوری شده را صادر کنید، بلکه با ارائه فرصت هایی برای بررسی، از اعتبار سنجی داده ها اطمینان حاصل کنید. به شاخص های اولیه؛
• وجود یک لایه سرویس به شما امکان می‌دهد تجزیه و تحلیل داده‌های سرتاسر (نسب داده)، استفاده از ابزار حسابرسی داده‌های یکپارچه، رویکردهای کلی برای برجسته کردن تغییرات دلتا، کار با کیفیت داده، مدیریت بار، نظارت و ابزارهای تشخیص خطا و تسریع در حل مشکل

این رویکرد به تجزیه همچنین سیستم را در برابر تغییر مقاوم تر می کند (در مقایسه با "ساختار یکپارچه") - ضد شکنندگی آن را تضمین می کند:

• تغییرات از طرف سیستم های منبع در مرحله مرحله پردازش می شوند - در هسته، فقط جریان هایی که تحت تأثیر این جداول مرحله بندی هستند اصلاح می شوند، تأثیر بر ویترین فروشگاه ها حداقل است یا وجود ندارد.
• تغییرات در الزامات از جانب مصرف کنندگان بیشتر در ویترین فروشگاه ها پردازش می شود (اگر این نیاز به اطلاعات اضافی که هنوز در فروشگاه وجود ندارد) انجام می شود.

در ادامه به بررسی هر یک از اجزای ارائه شده در بالا می پردازیم و با کمی جزئیات بیشتر به آنها نگاه می کنیم.

هسته سیستم

بیایید از وسط شروع کنیم - هسته سیستم یا لایه میانی. به عنوان لایه هسته برچسب گذاری شده است. هسته نقش یکپارچه سازی داده ها را بازی می کند - به ساختارهای یکنواخت، کتاب های مرجع، کلیدها می رساند. اینجاست که کار اصلی با کیفیت داده انجام می شود - تمیز کردن، تبدیل، یکسان سازی.

وجود این مؤلفه به شما امکان می دهد تا از جریان های داده ای استفاده مجدد کنید که داده های اولیه دریافت شده از سیستم های منبع را به یک فرمت یکپارچه خاص با پیروی از قوانین و الگوریتم های کلی تبدیل می کند و اجرای یک عملکرد مشابه را به طور جداگانه برای هر ویترین برنامه کاربردی تکرار نکنید. علاوه بر استفاده ناکارآمد از منابع، ممکن است منجر به اختلاف در داده ها نیز شود.
هسته مخزن در یک مدل داده پیاده سازی می شود، در حالت کلی، هم از مدل های سیستم های منبع و هم از قالب ها و ساختارهای مصرف کنندگان متفاوت است.

مدل هسته انبار و مدل داده سازمانی

نگرانی اصلی لایه ذخیره سازی میانی ثبات است. به همین دلیل است که تمرکز اصلی در اینجا بر روی مدل داده است. معمولاً از آن به عنوان "مدل داده های شرکتی" یاد می شود. متأسفانه نوعی هاله از افسانه ها و پوچ ها در اطراف آن شکل گرفته است که گاه منجر به امتناع کلی از ساخت آن می شود اما بیهوده.

افسانه 1. یک مدل داده سازمانی یک مدل بزرگ با هزاران موجودیت (جدول) است.
در حقیقت. در هر حوزه موضوعی، در هر حوزه تجاری، در داده های هر شرکت، حتی پیچیده ترین، تعداد کمی از نهادهای اساسی وجود دارد - 20-30.

افسانه 2. نیازی به توسعه هیچ "مدل خود" نیست - ما یک مدل مرجع صنعت می خریم - و همه چیز را مطابق آن انجام می دهیم. ما پول خرج می کنیم - اما نتیجه تضمینی می گیریم.
در حقیقت. مدل های مرجع در واقع می توانند بسیار مفید باشند زیرا شامل تجربه صنعت در مدل سازی این حوزه است. از آنها می توانید ایده ها، رویکردها، شیوه های نامگذاری را جمع آوری کنید. "عمق پوشش" منطقه را بررسی کنید تا چیز مهمی نادیده گرفته نشود. اما بعید است بتوانیم از چنین مدلی خارج از جعبه استفاده کنیم - همانطور که هست. این همان افسانه ای است که به عنوان مثال، خرید یک سیستم ERP (یا CRM) و اجرای آن بدون هیچ گونه «سختی برای خودتان» است. ارزش چنین مدل هایی در انطباق آنها با واقعیت های این تجارت خاص، این شرکت خاص متولد می شود.

افسانه 3. توسعه یک مدل مخزن اصلی می‌تواند چندین ماه طول بکشد و در این مدت پروژه در واقع منجمد می‌شود. بعلاوه، این نیاز به حجم دیوانه کننده ای از جلسات و افراد زیادی دارد.
در حقیقت. مدل مخزن را می توان با مخزن به صورت تکراری، تکه تکه توسعه داد. برای مناطق بدون پوشش، "نقاط گسترش" یا "خرد" تنظیم شده است. برخی از "طرح های جهانی" اعمال می شود. در عین حال، باید بدانید چه زمانی باید متوقف شوید تا یک چیز فوق العاده جهانی از 4 جدول بدست نیاورید، که هم "قرار دادن داده ها" و هم (حتی دشوارتر) به دست آوردن آن دشوار است. و از نظر عملکرد بسیار نابهینه است.

توسعه مدل واقعاً زمان می برد. اما این زمان صرف شده برای "طراحی موجودیت ها" نیست - این زمان مورد نیاز برای تجزیه و تحلیل حوزه موضوعی، درک نحوه چیدمان داده ها است. به همین دلیل است که تحلیلگران از نزدیک درگیر این فرآیند هستند و کارشناسان مختلف کسب و کار نیز درگیر آن هستند. و این به صورت نقطه ای، انتخابی انجام می شود. و نه با تشکیل جلساتی با شرکت تعدادی مجنون، ارسال پرسشنامه های هنگفت و غیره.
تجزیه و تحلیل خوب کسب و کار و سیستم در ساخت یک مدل انبار اصلی کلیدی است. چیزهای زیادی برای درک وجود دارد: داده‌ها در کجا (در چه سیستم‌هایی) تولید می‌شوند، چگونه کار می‌کنند، در چه فرآیندهای تجاری در گردش هستند و غیره. تحلیل کیفی هرگز به یک سیستم واحد آسیب نرسانده است. در عوض، برعکس، مشکلات از "نقاط سفید" در درک ما ناشی می شود.

توسعه یک مدل داده، فرآیند اختراع و اختراع چیز جدیدی نیست. در واقع، مدل داده از قبل در شرکت وجود دارد. و فرآیند طراحی بیشتر شبیه "حفاری" است. مدل به دقت و با دقت از "خاک" داده های شرکت استخراج شده و در یک فرم ساختار یافته قرار می گیرد.

افسانه 4. کسب و کار ما در شرکت ما آنقدر پویا است و همه چیز به سرعت در حال تغییر است که ساختن یک مدل برای ما بی فایده است - قبل از اینکه این بخش از سیستم را به کار بگیریم منسوخ می شود.
در حقیقت. به یاد داشته باشید که عامل اصلی ثبات است. و بالاتر از همه، توپولوژی مدل. چرا؟ زیرا این مؤلفه است که محور است و بر هر چیز دیگری تأثیر می گذارد. ثبات نیز یک الزام برای مدل کرنل است. اگر یک مدل خیلی سریع منسوخ شود، به اشتباه طراحی شده است. رویکردهای اشتباه و "قوانین بازی" برای توسعه آن انتخاب شد. و همچنین موضوع تحلیل کیفی است. موجودیت های کلیدی مدل شرکتی به ندرت تغییر می کنند.
اما اگر به ذهنمان خطور کرد که برای شرکتی بسازیم که مثلاً شیرینی‌فروشی می‌کند، به‌جای فهرست «محصولات»، «شیرینی»، «کیک» و «کیک» درست کنیم. سپس هنگامی که پیتزا در لیست کالاها ظاهر می شود - بله، باید تعداد زیادی جدول جدید وارد کنید. و این فقط یک موضوع رویکرد است.

افسانه 5. ایجاد یک مدل شرکتی یک تجارت بسیار جدی، پیچیده و مسئولانه است. و اشتباه کردن ترسناک است.
در حقیقت. مدل هسته، اگرچه باید پایدار باشد، هنوز "ریخته گری فلزی" نیست. مانند هر راه حل طراحی دیگری، ساختار آن قابل بازنگری و اصلاح است. فقط لازم نیست این کیفیت آن را فراموش کنید. اما این به هیچ وجه به این معنی نیست که "شما نمی توانید روی آن نفس بکشید". و این بدان معنا نیست که راه حل های موقت و "خرد" هایی که باید برای بازیافت برنامه ریزی شوند غیرقابل قبول هستند.

افسانه 6. اگر منبع داده ما، به عنوان مثال، یک سیستم داده مرجع (یا یک سیستم مدیریت داده اصلی - MDM) باشد، باید قبلاً به روشی دوستانه با مدل شرکت مطابقت داشته باشد (مخصوصاً اگر اخیراً طراحی شده باشد و وقت نداشته باشد به دست آوردن "سمت"، "سنت "و کلبه های موقت). معلوم می شود که برای این مورد - ما به یک مدل هسته نیاز نداریم؟
در حقیقت. بله، در این مورد، ساخت مدل اصلی مخزن بسیار تسهیل می شود - از آنجا که ما از یک مدل مفهومی سطح بالا و آماده پیروی می کنیم. اما اصلاً منتفی نیست. چرا؟ زیرا هنگام ساخت یک مدل از یک سیستم خاص، برخی از قوانین خود اعمال می شود - از چه نوع جداولی استفاده شود (برای هر موجودیت)، چگونه داده ها را نسخه بندی کنیم، با چه جزئیاتی تاریخچه را حفظ کنیم، چه ویژگی های متا (فیلدهای فنی) برای استفاده) و غیره

علاوه بر این، مهم نیست که چقدر سیستم فوق العاده و همه جانبه داده های مرجع و MDM داریم، به عنوان یک قاعده، تفاوت های ظریف مرتبط با وجود دایرکتوری های محلی "در حدود یکسان" در سایر سیستم های حسابداری وجود خواهد داشت. و این مشکل، چه بخواهیم چه نخواهیم، ​​باید در مخزن حل شود - از این گذشته، گزارش ها و تجزیه و تحلیل ها در اینجا جمع آوری می شوند.

لایه داده اولیه (یا مرحله بندی تاریخی یا لایه عملیاتی)

روی آن به عنوان لایه داده اولیه تعیین شده است. نقش این مؤلفه: ادغام با سیستم های منبع، بارگیری و ذخیره داده های اولیه، و همچنین پاکسازی اولیه داده ها - بررسی انطباق با قوانین کنترل فرمت-منطقی، ثابت شده در "توافقنامه رابط تعامل" با منبع.
علاوه بر این، این مؤلفه مشکل بسیار مهمی را برای مخزن حل می کند - تخصیص "دلتای واقعی تغییرات" - صرف نظر از اینکه آیا منبع به شما اجازه می دهد تغییرات در داده ها را ردیابی کنید یا خیر و چگونه (با چه معیاری می توان آنها را "گرفت" کرد. ). به محض اینکه داده ها وارد مرحله بندی شدند - برای همه لایه های دیگر، موضوع تخصیص دلتا از قبل مشخص است - به لطف برچسب گذاری با متا ویژگی ها.

داده های این لایه در ساختارهایی تا حد امکان نزدیک به سیستم منبع ذخیره می شوند - به منظور حفظ داده های اولیه تا حد امکان به شکل اصلی خود. نام دیگر این مؤلفه «لایه عامل» است.
چرا فقط از اصطلاح به خوبی تثبیت شده "صحنه سازی" استفاده نمی کنید؟ واقعیت این است که قبل از "عصر داده های بزرگ و VLDB"، فضای دیسک بسیار گران بود - و اغلب داده های اولیه، اگر حفظ شوند، فقط برای مدت زمان محدودی بودند. و غالباً نام " صحنه سازی " خوانده می شود قابل تمیز کردنبافر
اکنون فن‌آوری‌ها پا پیش گذاشته‌اند - و ما نه تنها می‌توانیم تمام داده‌های اولیه را ذخیره کنیم، بلکه می‌توانیم آنها را با درجه‌ای از جزئیات ممکن، تاریخی کنیم. این بدان معنا نیست که ما نباید رشد داده ها را کنترل کنیم و نیازی به مدیریت چرخه عمر اطلاعات، بهینه سازی هزینه ذخیره سازی داده ها، بسته به "دمای" استفاده - یعنی. گرفتن «داده‌های سرد» که تقاضای کمتری دارند به رسانه‌ها و بسترهای ذخیره‌سازی ارزان‌تر.

حضور «صحنه پردازی تاریخی» چه چیزی به ما می دهد:

• امکان اشتباه کردن (در ساختارها، در الگوریتم های تبدیل، در دانه بندی تاریخ) - با داشتن داده های اولیه کاملاً تاریخی در منطقه در دسترس برای ذخیره سازی، ما همیشه می توانیم جداول خود را بارگیری مجدد کنیم.
• فرصتی برای فکر کردن - می‌توانیم وقت خود را صرف کار کردن بخش بزرگی از هسته در این تکرار خاص از توسعه ذخیره‌سازی کنیم، زیرا در صحنه پردازی ما، به هر حال، وجود خواهد داشت، و با افق زمانی یکنواخت (یک نقطه «مرجع تاریخ» وجود خواهد داشت).
• امکان تجزیه و تحلیل - ما حتی داده هایی را که دیگر در منبع نیستند ذخیره خواهیم کرد - آنها می توانند در آنجا بازنویسی شوند، به بایگانی بروند و غیره. - با ما، آنها برای تجزیه و تحلیل در دسترس هستند.
• امکان ممیزی اطلاعات - به لطف دقیق ترین اطلاعات اولیه، ما می توانیم بفهمیم که دانلود چگونه برای ما کار کرده است، که به چنین ارقامی رسیدیم (برای این، ما همچنین باید علامت گذاری با ویژگی های متا و ابرداده مربوطه داشته باشیم. که دانلود روی آن کار می کند - این توسط لایه سرویس تصمیم می گیرد).

چه مشکلاتی در هنگام ساختن یک "صحنه سازی تاریخی" ممکن است ایجاد شود:

• تنظیم الزامات برای یکپارچگی معاملاتی این لایه راحت است، اما تمرین نشان می دهد که دستیابی به این امر دشوار است (این بدان معناست که در این زمینه ما یکپارچگی ارجاعی جداول والدین و فرزند را تضمین نمی کنیم) - تراز یکپارچگی در مراحل بعدی رخ می دهد. لایه های؛
• این لایه شامل حجم های بسیار بزرگی است (حجم ترین در فضای ذخیره سازی - با وجود تمام افزونگی ساختارهای تحلیلی) - و شما باید بتوانید چنین حجم هایی را مدیریت کنید - هم از نظر بار و هم از نظر درخواست (در غیر این صورت، می توانید به طور جدی عملکرد کل ذخیره سازی را کاهش می دهد).

چه چیز دیگری در مورد این لایه جالب است.
اولاً، اگر از پارادایم «فرایندهای بارگیری سرتاسر» دور شویم، قاعده «کاروان با سرعت آخرین شتر حرکت می‌کند» دیگر برای ما کارساز نیست، به عبارت دقیق‌تر، «کاروان» را رها می‌کنیم. اصل و تغییر به اصل "نقاله": ما داده ها را از منبع برداشتیم - در لایه خود قرار دادیم - آماده برداشتن قسمت بعدی. معنیش اینه که
1) ما منتظر نمی مانیم تا پردازش در لایه های دیگر انجام شود.
2) ما به برنامه زمانی برای ارائه داده ها توسط سیستم های دیگر وابسته نیستیم.
به عبارت ساده، ما یک فرآیند بارگذاری را برنامه ریزی می کنیم که داده ها را از یک منبع از طریق یک روش خاص برای اتصال به آن می گیرد، بررسی می کند، دلتا را تخصیص می دهد - و داده ها را در جداول مرحله بندی هدف قرار می دهد. و این همه است.

ثانیا، این فرآیندها، همانطور که می بینید، بسیار ساده هستند - ممکن است به طور پیش پا افتاده، از نقطه نظر منطق، بگوییم. این بدان معنی است که آنها می توانند به خوبی بهینه و پارامتر شوند، بار سیستم ما را کاهش داده و روند اتصال منابع (زمان توسعه) را سرعت می بخشد.
برای اینکه این اتفاق بیفتد، باید به خوبی ویژگی‌های فناوری پلتفرمی را که این مؤلفه روی آن کار می‌کند بدانید - و سپس می‌توانید یک ابزار بسیار مؤثر بسازید.

لایه ویترین

لایه Data Mart مسئول تهیه و ارائه داده ها به کاربران نهایی - افراد یا سیستم ها است. در این سطح، نیازهای مصرف کننده تا حد امکان در نظر گرفته می شود - هم منطقی (مفهومی) و هم فیزیکی. این سرویس باید دقیقاً آنچه را که لازم است ارائه دهد - نه بیشتر، نه کمتر.

اگر مصرف کننده یک سیستم خارجی باشد، به عنوان یک قاعده، ساختارهای داده مورد نیاز و قوانین جمع آوری اطلاعات را دیکته می کند. یک رویکرد خوب رویکردی است که در آن مصرف کننده مسئول جمع آوری صحیح داده ها باشد. انبار داده آماده شد، ویترینی را تشکیل داد، امکان جمع آوری اطلاعات افزایشی (علامت گذاری با متا ویژگی ها برای برجسته سازی بعدی دلتای تغییرات) را فراهم کرد و سپس سیستم مصرف کننده خود کنترل می کند و مسئول نحوه استفاده از این ویترین است. اما برخی ویژگی‌ها وجود دارد: زمانی که سیستم یک جزء فعال برای جمع‌آوری داده‌ها ندارد - یا به یک جزء خارجی نیاز است که عملکرد یکپارچه‌سازی را انجام دهد، یا ذخیره‌سازی به عنوان یک "سکوی ادغام" عمل می‌کند - و افزایش صحیح را تضمین می‌کند. آپلود اطلاعات بیشتر - خارج از فضای ذخیره سازی. تفاوت های ظریف بسیاری در اینجا ظاهر می شود، و قوانین تعامل رابط باید توسط هر دو طرف فکر و درک شود (اما، مثل همیشه، وقتی صحبت از ادغام می شود). به عنوان یک قاعده، پاکسازی / بایگانی معمول داده ها برای چنین داده هایی اعمال می شود (به ندرت لازم است که این "داده های انتقال" برای مدت طولانی ذخیره شود).

مهمترین آنها از نظر وظایف تحلیلی، ویترین های "برای مردم" هستند - به طور دقیق تر، برای ابزارهای BI که با آنها کار می کنند.
با این حال، دسته‌ای از «کاربران به‌ویژه پیشرفته» - تحلیلگران، پژوهشگران داده - وجود دارد که برای پر کردن سیستم‌های تخصصی خارجی به ابزارهای BI یا فرآیندهای نظارتی نیاز ندارند. آنها به نوعی "ویترین فروشگاه های رایج" و "جعبه شنی مخصوص خود" نیاز دارند، جایی که بتوانند جداول و دگرگونی هایی را بنا به صلاحدید خود ایجاد کنند. در این مورد، مسئولیت مخزن اطمینان از پر شدن این ویترین های رایج با داده ها مطابق با مقررات است.
به طور جداگانه، ما می توانیم مصرف کنندگانی را به عنوان ابزارهای داده کاوی - تجزیه و تحلیل عمیق داده ها برجسته کنیم. این ابزارها الزامات آماده سازی داده های خاص خود را دارند و دانشمندان داده نیز با آنها کار می کنند. برای ذخیره سازی، وظیفه به - دوباره پشتیبانی از سرویس برای بارگیری برخی از ویترین های فروشگاه با فرمت توافق شده کاهش می یابد.

با این حال، به ویترین های تحلیلی بازگردیم. اینها مواردی هستند که از دیدگاه طراحان ذخیره سازی در این لایه داده مورد توجه هستند.
به نظر من، بهترین رویکرد آزمایش شده برای طراحی داده‌های مارت، که تقریباً تمام پلتفرم‌های BI اکنون به آن «تیز» شده‌اند، رویکرد رالف کیمبال است. به عنوان شناخته شده است مدل سازی ابعادی - مدل سازی چند بعدی انتشارات زیادی در این زمینه وجود دارد. به عنوان مثال، قوانین اساسی را می توان در انتشارات مارگا راس یافت. و البته، شما می توانید از استاد مدل سازی چند بعدی توصیه کنید. یکی دیگر از منابع مفید، نکات کیمبال است
رویکرد چند بعدی برای ایجاد ویترین ها به خوبی توصیف و کار شده است - هم توسط "مبلغان روش" و هم توسط فروشندگان پیشرو نرم افزار، که منطقی نیست در اینجا با جزئیات در مورد آن صحبت کنیم - منبع اصلی همیشه ارجح است. .

من می خواهم فقط یک تاکید داشته باشم. «گزارش و تحلیل» متفاوت است. "گزارش سنگین" وجود دارد - گزارش های از قبل سفارش داده شده که در قالب فایل تولید می شوند و از طریق کانال های تحویل ارائه شده به کاربران تحویل داده می شوند. و سپس داشبوردها وجود دارد - داشبوردهای BI. در هسته آنها، اینها برنامه های کاربردی وب هستند. و زمان پاسخگویی این اپلیکیشن ها مانند سایر اپلیکیشن های تحت وب است. این بدان معناست که زمان عادی برای رفرش پنل BI چند ثانیه است نه دقیقه. مهم است که این را در هنگام طراحی راه حل خود در نظر داشته باشید. چگونه می توان به این امر دست یافت؟ روش بهینه سازی استاندارد: ما به این می پردازیم که زمان پاسخ از چه چیزی تشکیل شده است و چه چیزی می توانیم تأثیر بگذاریم. بیشترین زمان تلف شده چیست؟ برای خواندن پایگاه داده فیزیکی (دیسک)، برای انتقال داده از طریق شبکه. چگونه می توان میزان داده های خوانده شده و ارسال شده در یک درخواست را کاهش داد؟ پاسخ واضح و ساده است: شما باید داده ها را جمع آوری کنید، یا یک فیلتر را برای جداول بزرگ جداول واقعی شرکت کننده در پرس و جو اعمال کنید، و پیوستن جداول بزرگ را حذف کنید (اشاره به جداول واقعیت فقط باید از طریق ابعاد باشد).

BI برای چیست؟ چگونه راحت است؟ چرا مدل چند بعدی موثر است؟
BI به کاربر اجازه می دهد تا آنچه را که کوئری های موقت نامیده می شود اجرا کند. چه مفهومی داره؟ این بدان معنی است که ما از قبل درخواست دقیق را نمی دانیم، اما می دانیم که کاربر در چه جنبه هایی می تواند درخواست کند. کاربر با انتخاب فیلترهای BI مناسب چنین درخواستی را ایجاد می کند. و وظیفه توسعه‌دهنده BI و طراح ویترین این است که چنین منطقی از برنامه را ارائه دهند تا داده‌ها یا فیلتر یا جمع شوند و از موقعیتی که داده‌های بیش از حد درخواست می‌شود جلوگیری می‌کند - و برنامه "هنگ می‌زند". معمولاً آنها با اعداد جمع‌آوری شده شروع می‌کنند، سپس به اطلاعات دقیق‌تر می‌پردازند، اما در طول مسیر، فیلترهای لازم را نصب می‌کنند.

همیشه تنها ساختن "ستاره مناسب" و به دست آوردن یک ساختار مناسب برای BI کافی نیست. گاهی اوقات لازم است در جایی غیرعادی سازی را اعمال کنید (در حالی که به گذشته نگاه می کنید که چگونه این کار بر بار تأثیر می گذارد) و جایی برای ساخت ویترین ها و مصالح ثانویه. فهرست ها یا پیش بینی ها را در جایی اضافه کنید (بسته به DBMS).

بنابراین، از طریق "آزمایش و خطا"، می توانید ساختاری بهینه برای BI دریافت کنید - که ویژگی های هر دو DBMS و پلت فرم BI و همچنین الزامات کاربر برای ارائه داده ها را در نظر می گیرد.
اگر داده‌ها را از «هسته» بگیریم، چنین پردازشی از ویترین فروشگاه‌ها ماهیت محلی خواهد داشت، بدون اینکه به هیچ وجه بر پردازش پیچیده داده‌های اولیه که مستقیماً از سیستم‌های منبع به دست می‌آیند تأثیر بگذارد - ما فقط داده‌ها را به قالبی مناسب «تغییر» می‌دهیم. برای BI. و ما می توانیم این کار را بارها، به روش های مختلف، مطابق با نیازهای مختلف انجام دهیم. انجام این کار روی داده‌های هسته بسیار آسان‌تر و سریع‌تر از جمع‌آوری از «اولیه» است (ساختار و قوانین آن، همانطور که می‌دانیم، می‌تواند «شناور» نیز باشد).

لایه سرویس

لایه سرویس وظیفه اجرای توابع عمومی (سرویس) را بر عهده دارد که می تواند برای پردازش داده ها در لایه های مختلف ذخیره سازی - مدیریت بار، مدیریت کیفیت داده ها، ابزارهای تشخیص مشکل و نظارت و غیره استفاده شود.
وجود این سطح شفافیت و جریان های ساختاری داده را در ذخیره سازی فراهم می کند.

این لایه شامل دو منطقه ذخیره سازی داده است:

• ناحیه ابرداده - برای مکانیسم کنترل بارگذاری داده استفاده می شود.
• منطقه کیفیت داده - برای اجرای بررسی های کیفیت داده های آفلاین (یعنی آنهایی که مستقیماً در فرآیندهای ETL تعبیه نشده اند).

شما می توانید فرآیند مدیریت بار را به روش های مختلف سازماندهی کنید. یک روش ممکن این است: ما کل مجموعه جداول ذخیره سازی را به ماژول ها تقسیم می کنیم. ماژول می تواند شامل جداول تنها یک لایه باشد. جداول موجود در هر ماژول در یک فرآیند جداگانه بارگذاری می شوند. بیایید آن را صدا کنیم فرآیند کنترل ... شروع فرآیند کنترل بر اساس برنامه زمانی خود تنظیم شده است. فرآیند کنترل، فراخوانی‌های فرآیندهای اتمی را هماهنگ می‌کند، که هر کدام یک جدول هدف را بارگذاری می‌کنند، و همچنین شامل چند مرحله کلی است.
بدیهی است که به سادگی جداول مرحله بندی را به ماژول ها تقسیم کنید - بر اساس سیستم های منبع، یا به جای نقاط اتصال آنها. اما برای هسته، انجام این کار در حال حاضر دشوارتر است. در آنجا باید از یکپارچگی داده ها اطمینان حاصل کنیم، به این معنی که باید وابستگی ها را در نظر بگیریم. آن ها برخوردهایی وجود خواهد داشت که باید حل شود. و روش های مختلفی برای رفع آنها وجود دارد.

یک نکته مهم در مدیریت بار، ایجاد یک رویکرد سازگار برای مدیریت خطا است. خطاها بر اساس سطح شدت آنها طبقه بندی می شوند. هنگامی که یک خطای بحرانی رخ می دهد، فرآیند باید متوقف شود، و در اسرع وقت، زیرا وقوع آن نشان دهنده یک مشکل مهم است که می تواند منجر به خراب شدن داده ها در ذخیره سازی شود. بنابراین، مدیریت بار نه تنها در مورد شروع فرآیندها، بلکه توقف آنها و همچنین جلوگیری از شروع نابهنگام (به اشتباه) است.

برای عملکرد لایه سرویس، یک ساختار ابرداده ویژه ایجاد می شود. این قسمت اطلاعات مربوط به فرآیندهای بارگیری، مجموعه داده های بارگذاری شده، نقاط بازرسی که برای حفظ افزایش (که فرآیند به کدام نقطه خوانده شده است) و سایر اطلاعات خدمات لازم برای عملکرد سیستم ذخیره می کند.
توجه به این نکته ضروری است که تمام جداول هدف در همه لایه ها با مجموعه خاصی از متا فیلدها مشخص شده اند که یکی از آنها شناسه فرآیندی است که این ردیف را به روز کرده است. برای جداول درون یک مخزن، این علامت‌گذاری فرآیند اجازه می‌دهد تا روش ثابتی برای برجسته کردن دلتای تغییرات بعدی وجود داشته باشد. هنگام بارگذاری داده ها در لایه داده اولیه، وضعیت پیچیده تر است - الگوریتم تخصیص دلتا برای اشیاء بارگذاری شده مختلف ممکن است متفاوت باشد. اما منطق پردازش تغییرات پذیرفته شده و چرخاندن آنها بر روی میزهای هدف برای هسته و ویترین فروشگاه بسیار پیچیده تر از مرحله بندی است، جایی که همه چیز کاملاً بی اهمیت است - پارامترسازی و فکر کردن در مورد مراحل استاندارد قابل استفاده مجدد (رویه ها) آسان است.

من در اینجا وظیفه ای را برای پوشش کامل این موضوع - سازماندهی دانلود - تنظیم نمی کنم - فقط لهجه هایی را که ارزش توجه دارند برجسته می کنم.
این رویکرد تنها یکی از گزینه هاست. بسیار پاسخگو است. و "نمونه اولیه مفهومی" آن نوار نقاله تویوتا و سیستم به موقع بود. آن ها در اینجا ما از پارادایم گسترده "دانلود داده های شبانه" فاصله می گیریم و در طول روز در بخش های کوچک دانلود می کنیم - به محض اینکه داده ها در منابع مختلف آماده شوند: آنچه آمد - بارگیری شد. در همان زمان، ما بسیاری از فرآیندهای موازی در حال اجرا داریم. و «دم داغ» داده‌های تازه دائماً «چشمک می‌زند» - و به مرور زمان از بین می‌رود. ما باید چنین ویژگی را در نظر بگیریم. و در صورت لزوم، ویترین های سفارشی را با "برش ها" تشکیل دهید، جایی که همه چیز از قبل جامع است. آن ها دستیابی به کارایی و ثبات (یکپارچگی) در یک زمان غیرممکن است. ما به تعادل نیاز داریم - جایی یک چیز مهم است، جایی دیگر.

فراهم کردن امکانات ثبت و نظارت ضروری است. تمرین خوبی است که از رویدادهای تایپ شده استفاده کنید، جایی که می توانید پارامترهای مختلف را تنظیم کنید و سیستم اعلان را سفارشی کنید - اشتراک در رویدادهای خاص. زیرا بسیار مهم است که در صورت نیاز به مداخله مدیر سیستم، در اسرع وقت از آن مطلع شود و تمام اطلاعات تشخیصی لازم را دریافت کند. گزارش‌ها همچنین می‌توانند برای تجزیه و تحلیل مشکلات پس از وقوع، و همچنین برای بررسی رویدادهای خرابی سیستم، از جمله استفاده شوند. کیفیت داده.

طراحی و نگهداری مدل های داده انبار

چرا هنگام توسعه هر سیستمی که در آن پایگاه داده درگیر است (و به ویژه در یک انبار) توجه به طراحی مدل های داده مهم است؟ چرا مجموعه ای از جداول را در هر جایی پرتاب نکنید - حتی در یک ویرایشگر متن؟ چرا به "این عکس ها" نیاز داریم؟
به اندازه کافی عجیب، حتی توسعه دهندگان باتجربه چنین سوالاتی را می پرسند.
در واقع، بله، هیچ چیز مانع از ترسیم جداول - و شروع استفاده از آنها نمی شود. اگر ... اگر در همان زمان در سر (!) توسعه دهنده یک تصویر کلی منسجم از ساختاری که در حال مجسمه سازی است دارد. اگر چند توسعه دهنده وجود داشته باشد چه؟ اگر شخص دیگری از این جداول استفاده کند چه؟ و اگر زمان بگذرد - شخصی این منطقه را ترک کند و دوباره به آن بازگردد؟

آیا می توانید بدون مدل آن را بفهمید؟ در اصل، شما می توانید. و برای فهمیدن آن، و "تصاویر را روی یک تکه کاغذ مشخص کنید" و داده ها را "پاک کنید - حل کنید". اما استفاده از یک مصنوع آماده - یک مدل داده بسیار ساده تر، واضح تر و سریعتر است. و همچنین "منطق دستگاه آن" را درک کنید - یعنی. خوب است که قوانین کلی بازی داشته باشیم.

و مهم ترین چیز حتی این نیست. مهمترین چیز این است که هنگام طراحی یک مدل، ما مجبور هستیم (فقط بدون گزینه!) به بررسی دقیق و عمیق تر موضوع، ویژگی های دستگاه داده و استفاده از آنها در موارد مختلف تجاری بپردازیم. و آن سؤالاتی که به راحتی «کنار می‌زدیم» به‌عنوان پیچیده، «محو» می‌شدیم با پرتاب نشانه‌هایمان، بدون اینکه دقیقاً تلاش کنیم. طرحمدل - ما مجبور خواهیم شد در حال حاضر، هنگام تجزیه و تحلیل و طراحی، ارائه و تصمیم بگیریم، و نه بعدا - زمانی که گزارش بسازیم و به "چگونه موارد ناسازگار را کاهش دهیم" و هر بار "چرخ را دوباره اختراع کنیم" فکر کنیم.

این رویکرد یکی از آن شیوه های مهندسی است که به شما امکان می دهد سیستم های ضد شکننده ایجاد کنید. از آنجایی که آنها به وضوح مرتب، شفاف، مناسب برای توسعه هستند، و همچنین "محدودیت های شکنندگی" آنها بلافاصله قابل مشاهده است - می توانید "مقیاس فاجعه" را با ظاهر شدن الزامات جدید و زمان مورد نیاز برای طراحی مجدد (در صورت نیاز) با دقت بیشتری تخمین بزنید.
بنابراین، مدل داده یکی از مصنوعات اصلی است که باید در طول توسعه سیستم حفظ شود. به روشی دوستانه، باید "روی میز" هر تحلیلگر، توسعه دهنده و غیره باشد. - همه کسانی که در پروژه های توسعه سیستم شرکت می کنند.

طراحی مدل های داده موضوعی بزرگ و مجزا است. دو رویکرد اصلی برای طراحی ذخیره سازی وجود دارد.
این رویکرد برای هسته به خوبی کار می کند موجودیت-رابطه - هنگامی که یک مدل نرمال شده (3NF) بر اساس مطالعه منطقه موضوعی، به طور دقیق تر، منطقه انتخاب شده آن ساخته می شود. همان "مدل شرکتی" که در بالا مورد بحث قرار گرفت در اینجا در حال بازی است.

هنگام طراحی ویترین مناسب است مدل چند بعدی ... این رویکرد به خوبی با درک کاربران تجاری مطابقت دارد - زیرا این مدلی است که برای درک انسان ساده و راحت است - افراد با مفاهیم قابل درک و آشنا از معیارها (شاخص ها) و بخش هایی که توسط آنها تجزیه و تحلیل می شوند عمل می کنند. و این به شما امکان می دهد تا به سادگی و به وضوح فرآیند جمع آوری الزامات را بسازید - ما مجموعه ای از "ماتریس های بخش ها و شاخص ها" را ترسیم می کنیم و با نمایندگان بخش های مختلف ارتباط برقرار می کنیم. و سپس آن را به یک ساختار می آوریم - "مدل تجزیه و تحلیل": "گذرگاه اندازه گیری" را تشکیل می دهیم و حقایقی را که بر روی آنها تعریف می شود، تعریف می کنیم. در طول مسیر، ما روی سلسله مراتب و قوانین تجمع کار می کنیم.

سپس رفتن به مدل فیزیکی با اضافه کردن عناصر بهینه سازی با در نظر گرفتن ویژگی های DBMS بسیار آسان است. به عنوان مثال، برای اوراکل پارتیشن بندی، مجموعه ای از ایندکس ها و غیره خواهد بود. برای Vertica، تکنیک های دیگری استفاده خواهد شد - مرتب سازی، تقسیم بندی، برش.
همچنین، ممکن است غیرعادی‌سازی خاصی مورد نیاز باشد - زمانی که ما عمدا افزونگی را در داده‌ها وارد می‌کنیم، که به لطف آن عملکرد پرس و جو را بهبود می‌بخشیم، اما در عین حال به‌روزرسانی داده‌ها را پیچیده می‌کنیم (زیرا افزونگی باید در حین بارگذاری داده در نظر گرفته شود و حفظ شود. روند). شاید، برای بهبود عملکرد، ما همچنین مجبور به ایجاد جداول انبوه اضافی یا استفاده از چنین ویژگی های DBMS اضافی به عنوان پیش بینی در Vertica باشیم.

بنابراین، هنگام مدل‌سازی داده‌های انبار، در واقع چندین مشکل را حل می‌کنیم:

• وظیفه ساخت یک مدل مفهومی (منطقی) از هسته - تجزیه و تحلیل سیستم و کسب و کار - تحقیق در مورد موضوع، وارد شدن به جزئیات و در نظر گرفتن تفاوت های ظریف "داده های زنده" و استفاده از آنها در تجارت.
• وظیفه ساخت یک مدل تجزیه و تحلیل - و سپس یک مدل مفهومی (منطقی) فروشگاه.
• وظیفه ساخت مدل های فیزیکی - مدیریت افزونگی داده ها، بهینه سازی با در نظر گرفتن ویژگی های DBMS برای پرس و جو و بارگذاری داده ها.

هنگام توسعه مدل‌های مفهومی، ممکن است ویژگی‌های یک DBMS خاص را که در حال طراحی یک ساختار پایگاه داده برای آن هستیم، در نظر نگیریم. علاوه بر این، ما می توانیم از یک مدل مفهومی برای ایجاد چندین مدل فیزیکی - برای DBMS های مختلف استفاده کنیم.

بیایید خلاصه کنیم.

• یک مدل داده مجموعه‌ای از «تصاویر زیبا» نیست، و فرآیند طراحی آن فرآیند ترسیم آنها نیست. این مدل درک ما از دامنه را منعکس می کند. و فرآیند تدوین آن، فرآیند مطالعه و تحقیق در آن است. این زمان تلف شده است. و اصلاً "نقاشی و نقاشی" نیست.
• مدل داده یک مصنوع طراحی است، راهی برای تبادل اطلاعات به روشی ساختاریافته بین اعضای تیم. برای انجام این کار، باید برای همه روشن باشد (این با علامت گذاری و توضیح ارائه می شود) و در دسترس (منتشر شده).
• مدل داده یکبار ایجاد و منجمد نمی شود، بلکه در فرآیند توسعه سیستم ایجاد و توسعه می یابد. قوانین توسعه آن را خودمان تعیین می کنیم. و ما می توانیم آنها را تغییر دهیم اگر ببینیم - چگونه این کار را بهتر، آسان تر و کارآمدتر انجام دهیم.
• مدل داده (فیزیکی) به شما امکان می‌دهد مجموعه‌ای از بهترین شیوه‌ها را با هدف بهینه‌سازی ادغام و استفاده کنید - یعنی. از تکنیک هایی استفاده کنید که قبلاً برای این DBMS کار کرده اند.

ویژگی های پروژه های انبار داده

اجازه دهید به جزئیات پروژه هایی بپردازیم که شرکت در چارچوب آنها انبارهای داده را ایجاد و توسعه می دهد. و بیایید از منظر تأثیر جنبه معماری به آنها نگاه کنیم. چرا برای چنین پروژه هایی ساخت یک معماری و از همان ابتدا مهم است؟ و این وجود یک معماری کاملاً فکر شده است که به پروژه انبار داده انعطاف‌پذیری می‌دهد، به شما امکان می‌دهد کار را به طور مؤثر بین اجراکنندگان توزیع کنید، و همچنین پیش‌بینی نتیجه را آسان‌تر کرده و فرآیند را قابل پیش‌بینی‌تر می‌کند.

انبار داده یک نرم افزار سفارشی است

انبار داده همیشه یک "توسعه سفارشی" است، نه یک راه حل جعبه ای. بله، برنامه های کاربردی BI مخصوص صنعت وجود دارد که شامل یک مدل داده مرجع، فرآیندهای ETL از پیش پیکربندی شده از منابع رایج (به عنوان مثال، سیستم های ERP)، مجموعه ای از پنل های استاندارد BI و گزارش ها می شود. اما در عمل، ذخیره سازی به ندرت اجرا می شود - به عنوان یک "جعبه". من حدود 10 سال است که با مخازن کار می کنم و هرگز چنین داستانی ندیده ام. همیشه برخی از تفاوت های ظریف در ارتباط با ویژگی های منحصر به فرد شرکت - هم تجارت و هم چشم انداز فناوری اطلاعات وجود دارد. بنابراین، امیدواری به ارائه معماری توسط «فروشنده» ارائه دهنده راه حل، تا حدی بی پروا است. معماری چنین سیستم هایی اغلب در خود سازمان "بالغ" می شود. یا توسط متخصصان شرکت پیمانکار که مجری اصلی پروژه است تشکیل می شود.

انبار داده یک پروژه یکپارچه سازی است

انبار داده اطلاعات را از بسیاری از سیستم های منبع بارگیری و پردازش می کند. و برای حفظ "روابط دوستانه" با آنها، باید بسیار مراقب آنها باشید. به طور خاص، لازم است بار روی سیستم های منبع به حداقل برسد، پنجره های "در دسترس بودن و در دسترس نبودن" در نظر گرفته شود، رابط های تعاملی با در نظر گرفتن معماری آنها انتخاب شود و غیره. سپس ذخیره‌سازی می‌تواند داده‌ها را در اسرع وقت و با فرکانس مورد نیاز دریافت کند. در غیر این صورت، شما به یک مدار پشتیبان "پیوند" می شوید که در بیشترین فرکانس عملیاتی به روز نمی شود.
علاوه بر این، باید "عامل انسانی" را نیز در نظر گرفت. ادغام فقط در مورد تعامل ماشین ها نیست. همچنین ارتباط بین مردم است.

انبار داده یک پروژه مشارکتی است

در یک شرکت بزرگ، چنین سیستمی به ندرت توسط یک تیم قابل انجام است. به عنوان یک قاعده، چندین تیم در اینجا کار می کنند که هر کدام یک مشکل خاص را حل می کنند.

معماری باید توانایی سازماندهی کارهای موازی آنها را فراهم کند و در عین حال یکپارچگی آن را حفظ کند و از تکرار کارکردهای یکسان در مکان های مختلف توسط افراد مختلف جلوگیری کند. علاوه بر تلاش های غیر ضروری، چنین تکراری می تواند بعداً منجر به اختلاف داده ها شود.

علاوه بر این، هنگامی که افراد و تیم های زیادی، اغلب پراکنده، در توسعه سیستم دخالت دارند، به ناچار این سوال مطرح می شود: چگونه می توان ارتباطات و تعامل اطلاعاتی بین آنها ایجاد کرد. هرچه رویکردها و شیوه های استاندارد و قابل فهم بیشتری استفاده شود، سازماندهی چنین کاری آسان تر، راحت تر و کارآمدتر است. و، در میان چیزهای دیگر، ارزش آن است که در مورد ترکیب "مصنوعات کاری" فکر کنیم، که در میان آنها برای انبارهای داده شماره 1 مدل های داده وجود دارد (به بخش قبلی مراجعه کنید).

انبار داده نسبت به سایر سیستم ها عمر طولانی تری دارد

برای روشن کردن - این بیانیه برای ذخیره سازی "زنده"، کار، یکپارچه با منابع کلیدی، دارای داده های تاریخی و ارائه اطلاعات و خدمات تحلیلی به بسیاری از بخش های شرکت صادق است.

چه دلیلی برای این باور دارم؟
اولاً، ساخت یک ذخیره سازی یک فرآیند بسیار منابع فشرده است: علاوه بر هزینه های واقعی تجهیزات، مجوزها برای نرم افزارهای تکنولوژیکی لازم و توسعه، تقریباً تمام سیستم ها و بخش های شرکت نیز در این امر دخیل هستند. تکرار کل این فرآیند از ابتدا یک بار دیگر ایده بسیار جسورانه ای است.

ثانیاً، اگر فضای ذخیره سازی معماری صحیحی داشته باشد، می تواند به راحتی از تغییرات سیستم های منبع، و ظهور نیازهای جدید از سوی کاربران نهایی و رشد حجم داده ها جان سالم به در ببرد.
اگر معماری درست باشد، جریان های اطلاعات شفاف هستند، پس چنین سیستمی را می توان برای مدت طولانی بدون خطر گیر افتادن در موقعیتی در هنگام ایجاد تغییرات به دلیل مشکلات در ارزیابی تأثیر، توسعه داد.

توسعه تدریجی تکراری

آخرین چیزی که مشتری دوست دارد، درگیر شدن در داستان با مخزن، این است که الزامات خود را برای یک یا دو سال ثابت کند، تا زمانی که یک مدل داده شرکتی کامل طراحی شود، همه منابع به طور کامل متصل شوند و غیره.

از نظر مشتریان، انبار داده اغلب مانند یک هیولا مطلق به نظر می رسد - وظایف، اهداف و افق توسعه سیستم بسیار حجیم است. و اغلب مشتری می ترسد که "به هزینه بودجه خود" بخش فناوری اطلاعات برخی از "مشکلات آنها" را حل کند. و باز هم با موضوع تعامل بین مردم و توانایی بیان آرام موضع و مذاکره مواجه هستیم.

رویکردهای معمارانه مناسب به شما امکان می دهد سیستم را به طور مکرر توسعه دهید، عملکرد را به تدریج افزایش دهید، بدون اینکه چندین سال به "توسعه" بروید قبل از شروع به دادن نتیجه.

اگرچه باید توجه داشت که "معجزه اتفاق نمی افتد" - و "شروع" نیز زمان می برد. برای ذخیره‌سازی‌ها، می‌تواند بسیار بزرگ باشد - از آنجایی که اینها مقادیر زیادی داده هستند، این داده‌های تاریخی است - برای دوره‌های قدیمی، زمانی که قوانین پردازش اطلاعات ممکن است با قوانین فعلی متفاوت باشد. بنابراین، زمان کافی برای کار تحلیلی، تعامل با سیستم های منبع و تعدادی "آزمایش و خطا"، از جمله تست های بارگذاری روی داده های واقعی، به زمان کافی نیاز دارد.

انبارهای داده - "داستان چند پروژه"

به سختی می توان یک مشتری تجاری را برای یک انبار داده مشخص کرد. و اعتقاد بر این است که (نه بدون دلیل) عامل کلیدی در موفقیت پروژه ساخت یک انبار، حمایت مدیریت شرکت - مستقیماً شخص اول است.
یک مخزن به ندرت به عنوان بخشی از یک پروژه ساخته و توسعه می یابد. به طور معمول، نیازهای مختلفی برای تلفیق و تجزیه و تحلیل داده ها وجود دارد، در پشت آنها مشتریان و گروه های کاربری مختلف قرار دارند. بنابراین، مخزن اغلب در چارچوب چندین پروژه موازی توسعه می یابد.

تعادل نوآوری و راه حل های اثبات شده

با وجود این واقعیت که موضوع ذخیره سازی بسیار "قدیمی" است (اگر چنین کلمه ای برای صنعت جوانی مانند IT قابل استفاده باشد) و نسبتا محافظه کارانه است. با این وجود، پیشرفت ثابت نمی ماند - و آن محدودیت هایی که قبلاً به دلیل دیسک های گران قیمت و کند، حافظه گران قیمت و غیره وجود داشت. - اکنون حذف شده اند. در عین حال، زمان تجدید نظر در برخی از رویکردهای معماری فرا رسیده است. علاوه بر این، این امر هم در مورد پلتفرم های تکنولوژیکی و هم در مورد معماری سیستم های کاربردی که بر اساس آنها ساخته شده اند، صدق می کند.

ایجاد تعادل در اینجا مهم است - و یک رویکرد نسبتاً "سبز" برای منابع و اطلاعات ذخیره شده حفظ شود. در غیر این صورت، می توانید خیلی سریع ذخیره سازی را به یک "روگرفت" نیمه ساختار یافته تبدیل کنید، که در صورت امکان کشف آن، با تلاش بسیار زیاد.
بله، ما فرصت های بیشتری داریم، اما این بدان معنا نیست که ما نیاز به انکار همه شیوه های انباشته شده و آزمایش شده داریم، که روشن است چگونه و چرا باید از آنها استفاده کنیم، و "بسیار بد" تنها توسط شبح مه آلود " نوآوری ها".
حفظ تعادل به معنای استفاده از روش‌ها و رویکردهای جدید است که در آن فرصت‌های جدیدی را می‌گشایند، اما در عین حال استفاده از روش‌های اثبات شده قدیمی - برای حل مشکلات فوری که لغو نشده‌اند.
ما به عنوان توسعه دهندگان و طراحان راه حل های کاربردی چه کاری می توانیم انجام دهیم؟ اول از همه، برای شناخت و درک تغییرات تکنولوژیکی پلتفرم هایی که روی آن ها کار می کنیم، قابلیت ها، ویژگی ها و مرزهای کاربردی آن ها.

بیایید به DBMS به عنوان حیاتی ترین و مهم ترین پلت فرم فناوری برای ذخیره سازی نگاه کنیم.
اخیراً، رانش واضحی از پایگاه‌های اطلاعاتی رابطه‌ای، که در ابتدا به‌عنوان «جهانی» ایجاد شده‌اند، به سمت تخصصی شدن وجود داشته است. برای مدت طولانی، فروشندگان پیشرو گزینه های مختلفی را منتشر می کنند - برای برنامه های کاربردی از کلاس های مختلف (OLTP، DSS و DWH). علاوه بر این، فرصت های اضافی برای کار با متن، داده های جغرافیایی و غیره ظاهر می شود.

اما این پایان کار نبود - محصولاتی ظاهر شدند که در ابتدا بر روی کلاس خاصی از وظایف متمرکز بودند، یعنی. DBMS تخصصی آنها ممکن است از مدل رابطه ای استفاده کنند یا نکنند. مهم است که آنها در ابتدا نه تنها برای ذخیره و پردازش «اطلاعات تجاری» به طور کلی، بلکه برای وظایف خاص "تیز" شوند.

ظاهراً تمرکز و تخصص دو گرایش مکمل یکدیگر هستند که به صورت دوره ای جایگزین یکدیگر می شوند و توسعه و تعادل را تضمین می کنند. و همچنین تکامل تدریجی (تدریجی) و تغییرات اساسی. به عنوان مثال، در دهه 90، مایکل استون بریکر یکی از نویسندگان مانیفست پایگاه داده نسل سوم بود که به وضوح این ایده را بیان کرد که جهان نیازی به انقلاب دیگری در دنیای پایگاه های داده ندارد. با این حال، 10 سال بعد، او آثاری را منتشر می کند که در آنها پیش نیازهای آغاز یک دوره جدید در دنیای DBMS - بر اساس تخصص آنها را اعلام می کند.
او بر این واقعیت تمرکز دارد که DBMS های جهانی رایج بر اساس یک معماری "یک اندازه مناسب برای همه" ساخته شده اند، که تغییرات در پلتفرم های سخت افزاری یا تقسیم برنامه ها به کلاس هایی را در نظر نمی گیرد که می توانید برای همه آنها را به کار ببرید. راه حل بهینه نسبت به اجرای الزامات جهانی
و او شروع به توسعه تعدادی پروژه مطابق با این ایده می کند. یکی از آنها - C-Store - یک DBMS ستونی است که در معماری هیچ چیز مشترک (SN) طراحی شده است، که در اصل به طور خاص برای سیستم های کلاس انبارهای داده ایجاد شده است. این محصول سپس با نام HP Vertica به بازار عرضه شد.

به نظر می رسد اکنون موضوع توسعه انبارهای داده وارد مرحله جدیدی از توسعه شده است. فن آوری ها، رویکردها و ابزارهای جدید ظاهر می شوند. مطالعه، آزمایش و کاربرد هوشمند آنها به ما امکان می دهد راه حل های واقعا جالب و مفیدی ایجاد کنیم. و آنها را به مرحله اجرا برسانید و از اینکه پیشرفت های شما در کار واقعی استفاده می شود و مفید هستند لذت ببرید.

پایان

در تهیه این مقاله، سعی کردم در درجه اول بر معماران، تحلیلگران و توسعه دهندگانی تمرکز کنم که مستقیماً با انبارهای داده کار می کنند. اما معلوم شد که او به ناچار "موضوع را کمی گسترده تر کرد" - و سایر دسته های خوانندگان در میدان دید قرار گرفتند. برخی از نکات بحث برانگیز به نظر می رسند، برخی واضح نیستند، برخی واضح هستند. افراد متفاوت هستند - با پیشینه ها، پیشینه ها و موقعیت های مختلف.
به عنوان مثال، سوالات مدیریتی معمولی عبارتند از "چه زمانی معماران را استخدام کنیم؟"، "چه زمانی معماری انجام دهیم؟" برای ما (توسعه دهندگان، طراحان) بسیار عجیب است، زیرا برای ما معماری سیستم با تولد آن ظاهر می شود - مهم نیست که از آن آگاه باشیم یا نه. و حتی اگر نقش رسمی یک معمار در یک پروژه وجود نداشته باشد، یک توسعه دهنده معمولی همیشه "معمار داخلی خود را نیز شامل می شود."

به طور کلی، مهم نیست که دقیقاً چه کسی نقش معمار را ایفا می کند - مهم این است که کسی سؤالات مشابهی بپرسد و پاسخ ها را بررسی کند. اگر معمار به وضوح مشخص شود، این تنها به این معنی است که او در درجه اول مسئول سیستم و توسعه آن است.
چرا موضوع «ضد شکنندگی» را مرتبط با این موضوع یافتم؟

منحصر به فرد ضد شکنندگی این است که به ما امکان می دهد با ناشناخته ها کار کنیم، در شرایطی که نمی دانیم دقیقاً چه کاری انجام می دهیم کاری انجام دهیم و به موفقیت برسیم./ نسیم نطلب /

بنابراین، بحران و درجه بالای عدم اطمینان بهانه ای به نفع نبود معماری نیست، بلکه عواملی است که نیاز آن را تقویت می کند.

Zaitsev S.L., Ph.D.

گروه های تکراری

گروه‌های تکراری ویژگی‌هایی هستند که یک نمونه از یک موجودیت می‌تواند بیش از یک مقدار داشته باشد. به عنوان مثال، یک فرد می تواند بیش از یک مهارت داشته باشد. اگر از نظر الزامات تجاری، ما نیاز به دانستن سطح مهارت برای هر یک داشته باشیم، و هر فرد فقط می تواند دو مهارت داشته باشد، می توانیم موجودیت نشان داده شده در شکل را ایجاد کنیم. 1.6. اینجا موجودیت است یک شخصبا دو ویژگی برای ذخیره مهارت ها و سطح مهارت برای هر کدام.

برنج. 1.6. این مثال از گروه های تکراری استفاده می کند.

مشکل تکرار گروه‌ها این است که نمی‌توانیم دقیقاً بدانیم که یک فرد چند مهارت دارد. در زندگی واقعی، برخی از افراد یک مهارت، برخی چندین و برخی هنوز هیچ مهارتی ندارند. شکل 1.7 مدل کاهش یافته به اولین شکل عادی را نشان می دهد. به موارد اضافه شده توجه کنید شناسه مهارت که هر کدام به طور منحصر به فرد شناسایی می کنند مهارت.

برنج. 1.7. مدل به اولین فرم عادی کاهش یافت.

یک واقعیت در یک مکان

اگر همان ویژگی در بیش از یک موجودیت وجود داشته باشد و یک کلید خارجی نباشد، این ویژگی زائد در نظر گرفته می شود. مدل منطقی نباید حاوی داده های اضافی باشد.

افزونگی به فضای بیشتری نیاز دارد، اما در حالی که کارایی حافظه مهم است، مشکل واقعی جای دیگری است. اطمینان از اینکه داده‌های اضافی همگام‌سازی شده‌اند، سربار است، و شما همیشه در معرض خطر مقادیر متناقض هستید.

در مثال قبلی مهارتبستگی دارد به شناسه شخصو از شناسه مهارتاین بدان معنی است که شما نخواهید داشت مهارتتا زمانی که ظاهر شود یک شخص،داشتن این مهارت این همچنین تغییر نام مهارت را دشوار می کند. لازم است هر ورودی را با نام مهارت پیدا کنید و برای هر شخصی که این مهارت را دارد تغییر دهید.

شکل 1.8 مدل را در حالت عادی دوم نشان می دهد. توجه داشته باشید که موجودیت اضافه شده است مهارت، و صفت عنوانمهارت به این نهاد منتقل می شود. سطح مهارت به ترتیب در تقاطع باقی ماند افراد و مهارت.

برنج. 1.8. در حالت عادی دوم، گروه تکرار شونده به موجودیت دیگری منتقل می شود. این انعطاف‌پذیری را برای اضافه کردن تعداد مورد نیاز مهارت و تغییر نام مهارت یا شرح مهارت در یک مکان فراهم می‌کند.

هر ویژگی به کلید بستگی دارد

هر ویژگی یک موجودیت باید به کلید اصلی آن موجودیت بستگی داشته باشد. در مثال قبلی نام مدرسهو منطقه جغرافیاییموجود در جدول یک شخصاما شخص را توصیف نکنید. برای دستیابی به سومین شکل عادی، باید ویژگی ها را به موجودیت منتقل کنید، جایی که آنها به کلید بستگی دارند. شکل 1.9. مدل را به شکل سوم عادی نشان می دهد.

برنج. 1.9. در فرم سوم عادی نام مدرسهو منطقه جغرافیاییبه نهاد منتقل می شود، جایی که مقادیر آنها به کلید بستگی دارد.

روابط چند به چند

ارتباط چند به چندواقعیت دنیای اطراف را منعکس می کند. توجه داشته باشید که در شکل 1.9، رابطه چند به چند بین وجود دارد شخصیو مدرسه... نگرش دقیقاً منعکس کننده این واقعیت است که یک شخصمی تواند در بسیاری مطالعه کند مدارسو در مدرسهمی تواند چیزهای زیادی یاد بگیرد PERSON.برای دستیابی به چهارمین شکل عادی، یک موجودیت انجمنی ایجاد می‌شود که با ایجاد یک ورودی جداگانه برای هر ترکیب منحصربه‌فرد مدرسه و فرد، رابطه انحصاری به بسیاری را حذف می‌کند. شکل 1.10 مدل را به شکل چهارم عادی نشان می دهد.

برنج. 1.10. در شکل چهارم عادی، یک رابطه یکنواخت به چند بین شخصیو مدرسهبا معرفی یک موجودیت انجمنی، که در آن یک ورودی جداگانه برای هر ترکیب منحصربه‌فرد اختصاص داده می‌شود، حل می‌شود. مدارسو افراد

تعاریف رسمی از اشکال عادی

تعاریف زیر از فرم های معمولی می تواند دلهره آور به نظر برسد. آنها را به عنوان فرمول هایی برای دستیابی به عادی سازی در نظر بگیرید. فرم های عادی بر اساس جبر رابطه ای هستند و می توانند به عنوان تبدیل های ریاضی تفسیر شوند. اگرچه این کتاب به بحث مفصل درباره اشکال عادی اختصاص ندارد، مدل‌سازان تشویق می‌شوند تا نگاه عمیق‌تری به موضوع بیندازند.

در یک رابطه داده شده R، ویژگی Y از نظر عملکردی به ویژگی X بستگی دارد. در شکل نمادین، RX -> RY (خوانده شده به عنوان "RX به طور عملکردی RY را تعریف می کند") - اگر و فقط اگر هر مقدار X در R دقیقاً با یک مرتبط باشد. مقدار Y در R (در هر زمان معین). ویژگی های X و Y می توانند مرکب باشند (Date CJ. Introduction to Database Systems. 6th edition. Ed. Williams: 1999, 848 pp.).

رابطه R با اولین شکل نرمال (1NF) مطابقت دارد اگر و فقط اگر همه دامنه های متعلق به آن فقط دارای مقادیر اتمی باشند (تاریخ، همانجا).

یک رابطه R مربوط به شکل عادی دوم (2NF) است اگر و فقط اگر با 1NF مطابقت داشته باشد، و هر ویژگی غیر کلیدی کاملاً به کلید اصلی وابسته است (تاریخ، همانجا).

یک رابطه R با سومین شکل عادی (3NF) مطابقت دارد، اگر و فقط اگر با 2NF مطابقت داشته باشد، و هر ویژگی غیرکلیدی به طور گذرا به کلید اصلی بستگی ندارد (تاریخ، همانجا).

رابطه R با فرم نرمال Boyes-Codd (BCNF) مطابقت دارد اگر و فقط در صورتی که هر تعیین کننده کاندیدای استفاده به عنوان یک کلید باشد.

توجه داشته باشید در زیر توضیح مختصری از برخی از اختصارات استفاده شده در تعاریف Date آورده شده است.

MVD (وابستگی چند ارزشی) یک وابستگی چند ارزشی است. فقط برای موجودیت هایی با سه یا بیشتر ویژگی استفاده می شود. در یک وابستگی چند ارزشی، مقدار ویژگی فقط به بخشی از کلید اصلی بستگی دارد.

FD (وابستگی عملکردی) - وابستگی عملکردی. با وابستگی تابعی، مقدار یک ویژگی به مقدار ویژگی دیگری که بخشی از کلید اصلی نیست بستگی دارد.

JD (وابستگی پیوستن) یک وابستگی به پیوستن است. با وابستگی اتحادیه، کلید اصلی موجودیت اصلی حداقل به نوادگان سطح سوم ردیابی می شود، در حالی که قابلیت استفاده در اتحادیه توسط کلید اصلی حفظ می شود.

این نسبت با چهارمین شکل نرمال (4NF) مطابقت دارد، اگر و فقط اگر MVD در R وجود داشته باشد، برای مثال A®B. در این مورد، تمام ویژگی های R از نظر عملکردی به A بستگی دارند. به عبارت دیگر، در R فقط وابستگی هایی (FD یا MVD) به شکل K®X وجود دارد (یعنی وابستگی عملکردی ویژگی X به نامزد برای استفاده به عنوان یک کلید K). بر این اساس، R اگر با BCNF مطابقت داشته باشد، الزامات 4NF را برآورده می کند و همه MVD ها در واقع FD هستند (تاریخ، همانجا).

برای پنجمین شکل نرمال، رابطه R وابستگی اتحاد (JD) * (X، Y،…، Z) را برآورده می کند اگر و فقط اگر R معادل پیش بینی های آن بر روی X، Y، ...، Z باشد، که در آن X، Y،...، Z زیرمجموعه ای از مجموعه صفات R است.

بسیاری از اشکال عادی دیگر برای انواع داده‌های پیچیده و موقعیت‌های خاص وجود دارد که از حوصله این بحث خارج است. هر علاقه‌مند به توسعه مدل مایل است سایر اشکال عادی را نیز بیاموزد.

فرم های عادی کسب و کار

در کتاب خود، کلایو فینکلشتاین (مقدمه ای بر مهندسی اطلاعات: از برنامه ریزی استراتژیک تا سیستم های اطلاعاتی. ریدینگ، ماساچوست: آدیسون-وسلی، 1989) رویکرد متفاوتی برای عادی سازی در نظر گرفت. اشکال عادی کسب و کار را بر حسب اجبار به آن اشکال تعریف می کند. بسیاری از مدل سازان این رویکرد را شهودی تر و عملی تر می دانند.

اولین فرم عادی کسب و کار (1BNF) گروه های تکرار شونده را به نهاد دیگری منتقل می کند. این موجودیت نام و ویژگی‌های کلیدی اولیه (کامپوزیت) خود را از موجودیت اصلی و گروه تکراری آن دریافت می‌کند.

دومین فرم معمولی کسب و کار (2BNF) ویژگی هایی را که تا حدی به کلید اصلی موجودیت دیگر وابسته هستند، نشان می دهد. کلید اولیه (کامپوزیت) این موجودیت، کلید اولیه موجودیتی است که در ابتدا در آن قرار داشت، همراه با کلیدهای اضافی که ویژگی کاملاً به آن بستگی دارد.

سومین شکل عادی کسب و کار (3BNF) ویژگی‌هایی را که مستقل از یک کلید اولیه هستند به موجودیت دیگری می‌برد، جایی که کاملاً به کلید اصلی آن موجودیت وابسته هستند.

فرم چهارم کسب و کار (4BNF) ویژگی هایی را می گیرد که به مقدار کلید اصلی بستگی دارد یا برای یک موجودیت ثانویه اختیاری است، جایی که کاملاً به مقدار کلید اصلی بستگی دارد یا باید (الزاما) در آن وجود داشته باشد. وجود، موجودیت.

اگر وابستگی بازگشتی یا وابستگی دیگری بین نمونه‌های موجودیت ثانویه وجود داشته باشد، یا اگر وابستگی بازگشتی بین نمونه‌های موجودیت اصلی آن وجود داشته باشد، پنجمین شکل عادی کسب‌وکار (5BNF) به‌عنوان یک موجودیت ساختاری ظاهر می‌شود.

مدل داده های منطقی تکمیل شده

مدل منطقی تکمیل شده باید الزامات فرم عادی کسب و کار سوم را برآورده کند و شامل تمام نهادها، ویژگی ها و روابط لازم برای پشتیبانی از الزامات داده و قوانین تجاری مرتبط با داده ها باشد.

همه موجودیت ها باید نام هایی داشته باشند که محتوای آنها را توصیف کند و توصیف یا تعریفی واضح، مختصر، کامل داشته باشد. یک پست آینده مجموعه ای اولیه از دستورالعمل ها برای شکل گیری صحیح نام ها و توضیحات موجودیت ها را پوشش خواهد داد.

موجودیت ها باید مجموعه کاملی از ویژگی ها را داشته باشند، به طوری که هر واقعیت مربوط به هر موجودیت را بتوان با ویژگی های آن نشان داد. هر ویژگی باید نامی داشته باشد که معنای آن را منعکس کند، یک نوع داده بولین، و یک توضیح یا تعریف واضح، کوتاه و کامل. در یک پست وبلاگ آینده، ما به مجموعه اولیه دستورالعمل‌ها برای قالب‌بندی صحیح نام‌ها و توضیحات ویژگی‌ها نگاه خواهیم کرد.

روابط باید شامل یک ساخت فعل باشد که رابطه بین موجودات را همراه با ویژگی هایی مانند کثرت، ضرورت وجود یا امکان عدم وجود یک رابطه توصیف می کند.

توجه داشته باشید کثرت رابطه حداکثر تعداد نمونه های موجودیت ثانویه را توصیف می کند که می تواند با یک نمونه از موجودیت اصلی مرتبط شود.ضرورت وجود یاامکان غیبت رابطه برای تعیین حداقل تعداد نمونه های موجودیت ثانویه که می تواند با یک نمونه از موجودیت اصلی مرتبط شود استفاده می شود.

مدل داده های فیزیکی

هنگامی که یک مدل منطقی کامل و کافی ایجاد کردید، آماده تصمیم گیری برای انتخاب یک پلت فرم پیاده سازی هستید. انتخاب پلت فرم بستگی به الزامات استفاده از داده ها و اصول استراتژیک شکل دادن به معماری شرکت دارد. انتخاب پلتفرم موضوعی پیچیده و فراتر از محدوده این کتاب است.

در ERwin، یک مدل فیزیکی یک نمایش گرافیکی از یک پایگاه داده در دنیای واقعی است. پایگاه داده فیزیکی از جداول، ستون ها و روابط تشکیل خواهد شد. مدل فیزیکی به پلتفرم انتخاب شده برای پیاده سازی و الزامات استفاده از داده ها بستگی دارد. مدل فیزیکی برای IMS بسیار متفاوت از مدل Sybase خواهد بود. مدل فیزیکی گزارش‌های OLAP با مدل OLTP (پردازش تراکنش آنلاین) متفاوت به نظر می‌رسد.

مدلساز داده و مدیر پایگاه داده (DBA) از مدل منطقی، الزامات استفاده و خط مشی معماری شرکتی برای توسعه یک مدل داده فیزیکی استفاده می کنند. می‌توانید برای بهبود عملکرد، مدل فیزیکی را غیرعادی کنید و برای پشتیبانی از الزامات استفاده، نماهایی ایجاد کنید. بخش‌های زیر به جزئیات فرآیند غیرعادی‌سازی و ایجاد نماها می‌پردازد.

این بخش یک نمای کلی از فرآیند ساخت یک مدل فیزیکی، جمع آوری الزامات استفاده از داده ها، تعریف اجزای یک مدل فیزیکی و ارائه مهندسی معکوس را ارائه می دهد. در نشریات بعدی به تفصیل به این موضوعات پرداخته شده است.

جمع آوری الزامات استفاده از داده ها

شما معمولاً الزامات استفاده از داده ها را در اوایل مصاحبه و جلسات کاری جمع آوری می کنید. در عین حال، الزامات باید تا حد امکان استفاده کاربر از داده ها را به طور کامل تعیین کند. نگرش سطحی و شکاف در مدل فیزیکی می تواند منجر به هزینه های برنامه ریزی نشده و تاخیر در اجرای پروژه شود. الزامات برای استفاده عبارتند از:

الزامات دسترسی و عملکرد

ویژگی های حجمی (تخمینی از مقدار داده ای که باید ذخیره شود) که به مدیر اجازه می دهد تا حجم فیزیکی پایگاه داده را نشان دهد.

تخمین تعداد کاربرانی که نیاز به دسترسی همزمان به داده ها دارند تا به شما در طراحی پایگاه داده خود برای سطوح عملکرد قابل قبول کمک کند

مجموعه ها، محورها و سایر داده های محاسبه شده یا مشتق شده که می توانند کاندیدای ذخیره سازی در ساختارهای داده پایدار در نظر گرفته شوند.

الزامات برای گزارش و پرس و جوهای استاندارد برای کمک به مدیر پایگاه داده در ساخت ایندکس ها

نماهایی (مداوم یا مجازی) که به کاربر در هنگام انجام عملیات تجمیع داده یا فیلتر کردن کمک می کند.

علاوه بر رئیس، منشی و کاربران، مدلساز، مدیر پایگاه داده و معمار پایگاه داده باید در جلسه الزامات استفاده شرکت کنند. الزامات داده های تاریخی کاربر باید مورد بحث قرار گیرد. مدت زمانی که داده ها نگهداری می شوند تأثیر قابل توجهی بر اندازه پایگاه داده دارد. اغلب، داده‌های قدیمی‌تر به شکل کلی ذخیره می‌شوند و داده‌های اتمی بایگانی یا حذف می‌شوند.

کاربران باید نمونه هایی از درخواست ها و گزارش ها را با خود به جلسه بیاورند. گزارش‌ها باید کاملاً تعریف شده باشند و باید مقادیر اتمی مورد استفاده برای هر فیلد خلاصه و خلاصه را شامل شوند.

اجزای مدل داده های فیزیکی

اجزای یک مدل داده فیزیکی جداول، ستون ها و روابط هستند. موجودیت های مدل منطقی احتمالاً در مدل فیزیکی به جداول تبدیل می شوند. ویژگی های بولی تبدیل به ستون می شوند. روابط منطقی به محدودیت هایی برای یکپارچگی روابط تبدیل خواهند شد. برخی از روابط منطقی را نمی توان در یک پایگاه داده فیزیکی پیاده سازی کرد.

مهندسی معکوس

هنگامی که یک مدل منطقی در دسترس نیست، ایجاد مجدد مدل از پایگاه داده موجود ضروری می شود. در ERwin به این فرآیند مهندسی معکوس می گویند. مهندسی معکوس می تواند به روش های مختلفی انجام شود. مدل ساز می تواند ساختارهای داده در پایگاه داده را بررسی کند و جداول را در یک محیط مدل سازی بصری بازسازی کند. می توانید زبان تعریف داده ها (DDL) را به ابزاری که از مهندسی معکوس پشتیبانی می کند (مانند Erwin) وارد کنید. ابزارهای پیشرفته ای مانند ERwin شامل توابعی است که ارتباط ODBC را با پایگاه داده موجود برای ایجاد یک مدل با خواندن مستقیم ساختارهای داده فراهم می کند. مهندسی معکوس با ERwin در پست آینده به تفصیل مورد بحث قرار خواهد گرفت.

استفاده از مرزهای عملکردی شرکت

هنگام ساخت یک مدل منطقی برای یک مدل ساز، مهم است که اطمینان حاصل شود که مدل جدید با مدل شرکت سازگار است. استفاده از مرزهای عملکردی شرکت به معنای مدل سازی داده ها بر اساس اصطلاحات مورد استفاده در یک شرکت است. نحوه استفاده از داده ها در یک شرکت سریعتر از خود داده ها تغییر می کند. در هر مدل منطقی، داده ها باید به شیوه ای جامع ارائه شوند، صرف نظر از حوزه تجاری که پشتیبانی می کند. موجودیت ها، ویژگی ها و روابط باید قوانین تجاری را در سطح شرکت تعریف کنند.

توجه داشته باشید برخی از همکاران من به این مرزهای عملکردی شرکت به عنوان مدل سازی در دنیای واقعی اشاره می کنند. مدل‌سازی دنیای واقعی، مدل‌ساز را تشویق می‌کند تا اطلاعات را بر حسب روابط و روابط ذاتی آن مشاهده کند.

استفاده از مرزهای عملکردی شرکت برای یک مدل داده ای که به طور مناسب ساخته شده است، مبنایی را برای پشتیبانی از نیازهای اطلاعاتی هر تعداد از فرآیندها و برنامه ها فراهم می کند، که شرکت را قادر می سازد تا به طور مؤثرتری از یکی از با ارزش ترین دارایی های خود - اطلاعات بهره برداری کند.

مدل داده سازمانی چیست؟

مدل داده سازمانی (EDM)شامل موجودیت ها، ویژگی ها و روابطی است که نشان دهنده نیازهای اطلاعاتی یک شرکت است. EDM معمولاً بر اساس حوزه‌های موضوعی طبقه‌بندی می‌شود که نشان‌دهنده گروه‌هایی از نهادهای مرتبط با پشتیبانی از نیازهای تجاری خاص است. برخی از حوزه‌های موضوعی ممکن است عملکردهای تجاری خاصی مانند مدیریت قرارداد را پوشش دهند، در حالی که برخی دیگر ممکن است شامل نهادهایی باشند که محصولات یا خدمات را توصیف می‌کنند.

هر مدل منطقی باید با دامنه موجود مدل داده شرکت مطابقت داشته باشد. اگر مدل منطقی این شرط را برآورده نمی کند، باید یک مدل دامنه به آن اضافه شود. این مقایسه تضمین می‌کند که مدل شرکتی بهبود یافته یا تعدیل شده است و تمام تلاش‌های مدل‌سازی منطقی در داخل شرکت هماهنگ می‌شوند.

EDMهمچنین شامل موجودیت های خاصی است که محدوده مقادیر را برای ویژگی های کلیدی تعریف می کند. این نهادها پدر و مادر ندارند و به عنوان مستقل تعریف می شوند. نهادهای مستقل اغلب برای حفظ یکپارچگی روابط استفاده می شوند. این موجودیت ها با چندین نام مختلف مانند جداول کد، جداول مرجع، جداول نوع یا جداول طبقه بندی شناسایی می شوند. ما از اصطلاح "شیء تجاری شرکتی" استفاده خواهیم کرد. یک شیء تجاری سازمانی موجودیتی است که حاوی مجموعه ای از مقادیر ویژگی است که مستقل از هر موجودیت دیگری است. اشیاء تجاری شرکتی باید به طور مداوم در یک شرکت استفاده شوند.

ساخت یک مدل داده شرکتی با افزایش

سازمان‌هایی هستند که مدل شرکت از ابتدا تا انتها در نتیجه یک تلاش هماهنگ ساخته شده است. از سوی دیگر، بیشتر سازمان‌ها با افزایش مقیاس، مدل‌های شرکتی نسبتاً کاملی را ایجاد می‌کنند.

ساختن به معنای ساختن چیزی به طور متوالی، لایه به لایه است، درست مانند صدف که یک مروارید رشد می کند. هر مدل داده ایجاد شده سهمی در شکل گیری EDM ارائه می دهد. ساختن یک EDM به این روش نیازمند مراحل مدلسازی اضافی برای افزودن ساختارها و دامنه های داده جدید یا تقویت ساختارهای داده موجود است. این امکان ایجاد یک مدل داده سازمانی را با افزایش، افزودن مکرر سطوح جزئیات و اصلاح می‌دهد.

مفهوم روش شناسی مدل سازی

چندین روش مدل سازی داده های بصری وجود دارد. ERwin از دو پشتیبانی می کند:

IDEF1X (تعریف یکپارچه سازی برای مدل سازی اطلاعات - توصیف یکپارچه مدل های اطلاعاتی).

IE (مهندسی اطلاعات).

IDEF1X یک متدولوژی خوب است و استفاده از نمادگذاری آن گسترده است

توصیف یکپارچه مدل های اطلاعاتی

IDEF1X یک روش مدل سازی داده بسیار ساختار یافته است که روش IDEF1 را که به عنوان استاندارد FIPS (استانداردهای پردازش اطلاعات فدرال) پذیرفته شده است، گسترش می دهد. IDEF1X از مجموعه ای بسیار ساختاریافته از انواع ساختار مدل سازی استفاده می کند و به مدل داده ای منجر می شود که قبل از در دسترس قرار گرفتن چنین اطلاعاتی نیاز به درک ماهیت فیزیکی داده ها دارد.

ساختار سفت و سخت IDEF1X مدل ساز را مجبور می کند تا ویژگی هایی را به موجودیت هایی اختصاص دهد که ممکن است با واقعیت های دنیای اطراف مطابقت نداشته باشد. برای مثال، IDEF1X نیاز دارد که همه زیرشاخه‌های موجودیت انحصاری باشند. این منجر به این واقعیت می شود که یک فرد نمی تواند هم مشتری و هم کارمند باشد. در حالی که تمرین واقعی چیز دیگری به ما می گوید.

مهندسی اطلاعات

از کلایو فینکستاین اغلب به عنوان پدر مهندسی اطلاعات یاد می شود، اگرچه مفاهیم مشابهی توسط جیمز مارتین با او به اشتراک گذاشته شد (مارتین، جیمز. مدیریت محیط پایگاه داده. رودخانه فوقانی سادل، نیوجرسی: پرنتیس هال، 1983). مهندسی اطلاعات از یک رویکرد مبتنی بر کسب‌وکار برای مدیریت اطلاعات استفاده می‌کند و از نماد متفاوتی برای نمایش قوانین تجاری استفاده می‌کند. اینترنت اکسپلورر به عنوان گسترش و توسعه نمادها و مفاهیم اصلی روش ER پیشنهاد شده توسط پیتر چن عمل می کند.

اینترنت اکسپلورر زیرساختی را برای پشتیبانی از نیازهای اطلاعاتی با ادغام برنامه ریزی استراتژیک شرکتی با سیستم های اطلاعاتی در حال توسعه فراهم می کند. این ادغام به مدیریت منابع اطلاعاتی اجازه می دهد تا با چشم انداز استراتژیک بلندمدت شرکت هماهنگی بیشتری داشته باشد. این رویکرد کسب‌وکار محور، بسیاری از مدل‌سازان را به انتخاب IE نسبت به روش‌های دیگر که تمایل به تمرکز بر چالش‌های توسعه کوتاه‌مدت دارند، سوق داده است.

IE مجموعه ای از اقدامات را پیشنهاد می کند که یک شرکت را به شناسایی تمام نیازهای اطلاعاتی خود برای جمع آوری و مدیریت داده ها و شناسایی روابط بین اشیاء اطلاعاتی سوق می دهد. در نتیجه، الزامات اطلاعاتی به وضوح بر اساس دستورالعمل‌های مدیریت بیان می‌شوند و می‌توانند مستقیماً به یک سیستم اطلاعات مدیریت ترجمه شوند که نیازهای اطلاعاتی استراتژیک را پشتیبانی می‌کند.

نتیجه

درک نحوه استفاده از ابزار مدل سازی داده مانند ERwin تنها بخشی از مشکل است. علاوه بر این، باید بدانید که چه زمانی وظایف مدل‌سازی داده حل می‌شوند و چگونه الزامات اطلاعاتی و قوانین تجاری که باید در مدل داده نشان داده شوند، جمع‌آوری می‌شوند. برگزاری جلسات کاری مساعدترین محیط را برای جمع آوری اطلاعات مورد نیاز در محیطی که شامل کارشناسان حوزه، کاربران و متخصصان فناوری اطلاعات است، فراهم می کند.

ایجاد یک مدل داده خوب مستلزم تجزیه و تحلیل و تحقیق در مورد نیازهای اطلاعاتی و قوانین تجاری است که از طریق جلسات کاری و مصاحبه جمع آوری شده است. مدل داده‌های حاصل باید در صورت امکان با مدل سازمانی مقایسه شود تا اطمینان حاصل شود که با مدل‌های شی موجود در تضاد نیست و شامل تمام اشیاء مورد نیاز است.

مدل داده شامل مدل های منطقی و فیزیکی است که الزامات اطلاعاتی و قوانین تجاری را نشان می دهد. مدل منطقی باید به شکل عادی سوم کاهش یابد. فرم عادی سوم، ناهنجاری‌های ساختار داده را محدود، اضافه، به‌روزرسانی و حذف می‌کند تا از اصل "یک واقعیت در یک مکان" پشتیبانی کند. الزامات اطلاعاتی جمع آوری شده و قوانین تجاری باید تجزیه و تحلیل و تحقیق شوند. آنها باید با مدل سازمانی مقایسه شوند تا اطمینان حاصل شود که با مدل‌های شی موجود در تضاد نیستند و همه اشیاء مورد نیاز را شامل می‌شوند.

در ERwin، مدل داده شامل هر دو مدل منطقی و فیزیکی است. ERwin رویکرد ER را پیاده‌سازی می‌کند و به شما اجازه می‌دهد تا اشیاء مدل منطقی و فیزیکی برای نشان دادن نیازهای اطلاعاتی و قوانین تجاری ایجاد کنید. اشیاء مدل منطقی شامل موجودیت‌ها، ویژگی‌ها و روابط هستند. اشیاء مدل فیزیکی شامل جداول، ستون‌ها و محدودیت‌های یکپارچگی روابط هستند.

یکی از انتشارات زیر مسائل مربوط به شناسایی موجودیت‌ها، تعریف انواع موجودیت، انتخاب نام و توصیف موجودیت، و همچنین برخی تکنیک‌ها برای جلوگیری از رایج‌ترین خطاهای مدل‌سازی مرتبط با استفاده از موجودیت‌ها را پوشش می‌دهد.

موجودیت ها باید مجموعه کاملی از ویژگی ها را داشته باشند، به طوری که هر واقعیت مربوط به هر موجودیت را بتوان با ویژگی های آن نشان داد. هر ویژگی باید نامی داشته باشد که معنای آن را منعکس کند، یک نوع داده بولین، و یک توضیح یا تعریف واضح، کوتاه و کامل. در یک پست وبلاگ آینده، ما به مجموعه اولیه دستورالعمل‌ها برای قالب‌بندی صحیح نام‌ها و توضیحات ویژگی‌ها نگاه خواهیم کرد. روابط باید شامل یک ساخت فعل باشد که رابطه بین موجودات را همراه با ویژگی هایی مانند کثرت، ضرورت وجود یا امکان عدم وجود یک رابطه توصیف می کند.

توجه داشته باشید کثرت رابطه حداکثر تعداد نمونه های موجودیت ثانویه را توصیف می کند که می تواند با یک نمونه از موجودیت اصلی مرتبط شود.وجوب وجود یا امکان عدم رابطه برای تعیین حداقل تعداد نمونه های موجودیت ثانویه که می تواند با یک نمونه از اصلی مرتبط شود خدمت می کند.

ارسال کار خوب خود را در پایگاه دانش ساده است. از فرم زیر استفاده کنید

دانشجویان، دانشجویان تحصیلات تکمیلی، دانشمندان جوانی که از دانش پایه در تحصیل و کار خود استفاده می کنند از شما بسیار سپاسگزار خواهند بود.

نوشته شده در http://www.allbest.ru/

• 1. مدل داده های رابطه ای
• 1.1 مدل داده های رابطه ای. تعاریف اساسی
• 1.2 عملیات در روابط
• 2. سیستم های اطلاعات شرکتی
• کتابشناسی - فهرست کتب

1. مدل داده های رابطه ای

1.1 مدل داده های رابطه ای. تعاریف اساسی

در رشته های ریاضی، مفهوم «جدول» با مفهوم «رابطه» (رابطه) مطابقت دارد. جدول یک شی از دنیای واقعی را منعکس می کند - یک موجودیت، و هر یک از خطوط آن یک نمونه خاص از موجودیت را منعکس می کند. هر ستون یک نام منحصر به فرد برای جدول دارد. رشته ها نامی ندارند، ترتیب آنها مشخص نیست و تعداد آنها از نظر منطقی نامحدود است. یکی از مزیت های اصلی مدل داده های رابطه ای همگنی است (هر ردیف در جدول دارای فرمت یکسانی است). این به کاربر بستگی دارد که تصمیم بگیرد که آیا موجودیت های مربوطه همگن هستند یا خیر. این مشکل مناسب بودن مدل را حل می کند.

مفاهیم اساسی:

* یک رابطه یک جدول دو بعدی است که حاوی داده هایی است.

* نهاد - یک شی از هر ماهیت، که داده های مربوط به آن در پایگاه داده ذخیره می شود. ویژگی ها ویژگی هایی هستند که یک موجودیت (ستون ها) را مشخص می کنند.

* درجه ارتباط تعداد ستون ها است.

* طرح رابطه - لیستی از نام ویژگی ها، به عنوان مثال، EMPLOYEE (شماره، نام کامل، سال تولد، موقعیت، بخش).

* دامنه - مجموعه ای از مقادیر ویژگی های یک رابطه (نوع داده).

* تاپل یک ردیف جدول است.

* Cardinality (Cardinality) - تعداد ردیف های جدول.

* کلید اصلی یک ویژگی است که ردیف های یک رابطه را به طور منحصر به فرد شناسایی می کند. یک کلید اولیه چند ویژگی، کلید اولیه ترکیبی نامیده می شود. کلید اصلی نمی تواند به طور کامل یا جزئی خالی (تهی) باشد. کلیدهایی که می توانند به عنوان کلید اصلی استفاده شوند، کلیدهای بالقوه یا جایگزین نامیده می شوند.

* کلید خارجی یک ویژگی (های) یک جدول است که می تواند به عنوان کلید اصلی جدول دیگر عمل کند. به کلید اصلی جدول دیگری ارجاع می دهد.

عادی سازی فرآیندی با هدف کاهش افزونگی اطلاعات در پایگاه داده است. علاوه بر خود داده ها، نام های مختلف، نام اشیاء و عبارات نیز می توانند در پایگاه داده عادی شوند.

یک پایگاه داده غیر عادی حاوی اطلاعات در یک یا چند جدول مختلف است. این تصور را ایجاد می کند که گنجاندن داده ها در یک جدول خاص به دلیل هیچ دلیل آشکاری نیست. این وضعیت می تواند بر امنیت داده ها، استفاده منطقی از فضای دیسک، سرعت جستجوها، کارایی به روز رسانی پایگاه داده و شاید مهمتر از همه، یکپارچگی اطلاعات ذخیره شده تأثیر منفی بگذارد. پایگاه داده قبل از عادی سازی ساختاری است که هنوز منطقاً به جداول قابل مدیریت تر و کوچکتر تقسیم نشده است.

فرم نرمال نوعی نشانگر سطح یا عمق عادی سازی پایگاه داده است. سطح نرمال سازی پایگاه داده با فرم معمولی که در آن قرار دارد مطابقت دارد.

1.2 عملیات در روابط

برای رساندن جدول به اولین فرم عادی (1NF)، دو قانون باید رعایت شود:

1. اتمی یا تقسیم ناپذیری. هر ستون باید دارای یک مقدار تقسیم ناپذیر باشد.

2. جدول نباید دارای ستون های تکراری یا گروهی از داده ها باشد.

به عنوان مثال، اگر یک جدول در یک فیلد حاوی آدرس کامل یک شخص (خیابان، شهر، کد پستی) باشد، قوانین 1NF را رعایت نمی کند، زیرا حاوی مقادیر مختلفی در یک ستون خواهد بود که این یک تخلف است. قانون اتمی یا اگر پایگاه داده حاوی داده‌هایی درباره فیلم‌ها باشد و شامل ستون‌های Actor1، Actor2، Actor3 باشد، از آنجایی که داده‌ها تکرار می‌شوند، با قوانین همخوانی ندارد.

عادی سازی باید با بررسی ساختار پایگاه داده برای سازگاری با 1NF آغاز شود. تمام ستون هایی که اتمی نیستند باید به ستون های تشکیل دهنده خود تقسیم شوند. اگر ستون های تکراری در جدول وجود دارد، باید یک جدول جداگانه انتخاب کنند.

برای آوردن جدول به اولین فرم عادی، باید:

* تمام فیلدهایی که حاوی اطلاعات چند بخشی هستند را پیدا کنید.

* داده هایی که می توانند به اجزاء تقسیم شوند باید در فیلدهای جداگانه قرار گیرند.

* داده های تکراری را به یک جدول جداگانه منتقل کنید.

* بررسی کنید که آیا همه جداول با شرایط اولین فرم عادی مطابقت دارند یا خیر.

برای آوردن جداول به فرم دوم عادی (2NF)، جداول باید از قبل در 1NF باشند. عادی سازی باید به ترتیب پیش برود.

اکنون، در حالت عادی دوم، شرط باید برآورده شود - هر ستونی که کلید نباشد (از جمله خارجی) باید به کلید اصلی بستگی داشته باشد. به طور معمول، این ستون ها، که مقادیری مستقل از کلید دارند، به راحتی قابل شناسایی هستند. اگر داده‌های موجود در ستون به کلیدی که ردیف را توصیف می‌کند مرتبط نباشد، باید آن‌ها را در جدول جداگانه‌ای جدا کرد. کلید اصلی باید به جدول قدیمی بازگردانده شود.

برای رساندن پایه به دومین فرم عادی، شما نیاز دارید:

* تمام ستون هایی را که مستقیماً به کلید اصلی این جدول وابسته نیستند، شناسایی کنید.

* فیلدهای مورد نیاز را در جداول کاربران و انجمن ها ایجاد کنید، از فیلدهای موجود انتخاب کنید یا کلیدهای اولیه را از کلیدهای جدید ایجاد کنید.

* هر جدول به کلید اصلی خود نیاز دارد

* کلیدهای خارجی ایجاد کنید و روابط آنها را بین جداول مشخص کنید. مرحله نهایی عادی سازی به 2NF، تخصیص کلیدهای خارجی برای ارتباط با جداول مرتبط خواهد بود. کلید اصلی یک جدول باید یک کلید خارجی در جدول دیگر باشد.

نکات:

راه دیگر برای تبدیل یک طرحواره به 2NF این است که به روابط بین جداول نگاه کنید. در حالت ایده آل، همه روابط یک به چند ایجاد کنید. بسیاری از روابط نیاز به بازسازی دارند.

جدولی که به درستی نرمال شده باشد هرگز ردیف های تکراری نخواهد داشت (دو یا چند ردیف که مقادیر آنها کلید نیستند و حاوی داده های یکسان هستند).

اگر پایگاه داده به شکل عادی دوم تبدیل شود و هر ستون غیر کلیدی مستقل از یکدیگر باشد، پایگاه داده به شکل سوم عادی خواهد بود. اگر تا این مرحله روند عادی سازی را به درستی دنبال کنید، ممکن است هیچ سوالی در مورد تبدیل به 3NF وجود نداشته باشد. باید توجه داشته باشید که اگر تغییر مقدار در یک ستون مستلزم تغییر در ستون دیگر باشد، 3NF نقض می شود.

برای رساندن پایه به فرم سوم عادی، شما نیاز دارید:

* تعیین کنید کدام فیلدها از کدام جداول وابستگی متقابل دارند، یعنی. فیلدهایی که بیشتر به یکدیگر بستگی دارند تا به کل ردیف.

* جداول تطبیق ایجاد کنید. اگر ستون مشکلی در مرحله 1 وجود دارد، جداول تقسیم شده را برای آن ایجاد کنید.

* کلیدهای اولیه را ایجاد یا اختصاص دهید. هر جدول باید یک کلید اصلی داشته باشد.

* کلیدهای خارجی مورد نیاز را ایجاد کنید که هر یک از روابط را تشکیل می دهند.

در شکل چهارم عادی، یک قانون اضافی این است که باید وابستگی های چند ارزشی را حذف کرد. به عبارت دیگر، تمام سطرهای جدول باید مستقل از یکدیگر باشند. وجود برخی از ردیف X نباید به این معنی باشد که ردیف Y نیز در جایی از این جدول است.

2. سیستم های اطلاعات شرکت

سیستم داده مدل رابطه ای

یک سیستم (از یونانی systema - یک کل، ترکیبی که از اجزا تشکیل شده است) مجموعه ای از عناصر است که با یکدیگر تعامل دارند و یکپارچگی و وحدت خاصی را تشکیل می دهند. در اینجا چند مفهوم وجود دارد که اغلب برای مشخص کردن یک سیستم استفاده می شود.

1. عنصر سیستم بخشی از یک سیستم است که هدف عملکردی خاصی دارد. عناصر پیچیده سیستم ها، به نوبه خود، متشکل از عناصر به هم پیوسته ساده تر، اغلب زیر سیستم نامیده می شوند.

2. سازماندهی سیستم - نظم داخلی، سازگاری تعامل عناصر سیستم، به ویژه در محدود کردن انواع حالت های عناصر در سیستم آشکار می شود.

3. ساختار سیستم - ترکیب، نظم و اصول تعامل عناصر سیستم که خصوصیات اساسی سیستم را تعیین می کند. اگر عناصر منفرد سیستم در سطوح مختلف فاصله داشته باشند و ارتباطات داخلی بین عناصر فقط از سطوح بالاتر به سطوح پایین تر و بالعکس سازماندهی شود، آنگاه از ساختار سلسله مراتبی سیستم صحبت می کنیم. ساختارهای سلسله مراتبی صرفاً عملاً نادر هستند، بنابراین، با گسترش این مفهوم، ساختار سلسله مراتبی معمولاً به عنوان چنین ساختارهایی درک می شود که در میان سایر ارتباطات، روابط سلسله مراتبی از اهمیت اولیه برخوردار است.

4. معماری سیستم - مجموعه ای از ویژگی های سیستم که برای کاربر ضروری است.

5. یکپارچگی سیستم - تقلیل ناپذیری اساسی خصوصیات سیستم به مجموع خصوصیات عناصر منفرد آن (ظهور خواص) و در عین حال وابستگی خصوصیات هر عنصر به مکان و مکان آن و عملکرد در داخل سیستم

سیستم اطلاعاتی مجموعه ای به هم پیوسته از ابزارها، روش ها و پرسنلی است که برای ذخیره، پردازش و صدور اطلاعات به منظور دستیابی به هدف تعیین شده استفاده می شود.

قانون فدرال "در مورد اطلاعات، اطلاعات و حفاظت اطلاعات" تعریف زیر را ارائه می دهد:

«سیستم اطلاعاتی مجموعه‌ای از اسناد (آرایه‌های اسناد) و فن‌آوری‌های اطلاعاتی، از جمله استفاده از فناوری رایانه و ارتباطات است که فرآیندهای اطلاعاتی را پیاده‌سازی می‌کند.»

طبقه بندی مقیاس

از نظر مقیاس، سیستم های اطلاعاتی به گروه های زیر تقسیم می شوند:

* تنها؛

* گروه؛

* شرکت های بزرگ، دارای شخصیت حقوقی.

سیستم اطلاعات شرکتی یک سیستم مقیاس پذیر است که برای اتوماسیون یکپارچه انواع فعالیت های اقتصادی شرکت های بزرگ و متوسط، از جمله شرکت های متشکل از گروهی از شرکت ها که نیاز به مدیریت واحد دارند، طراحی شده است.

یک سیستم اطلاعات شرکتی را می توان سیستمی در نظر گرفت که بیش از 80 درصد از بخش های یک شرکت را خودکار می کند.

اخیراً، در بسیاری از نشریات اختصاص داده شده به استفاده از فناوری اطلاعات در مدیریت اشیاء اقتصادی، اغلب از اصطلاح "سیستم های اطلاعات شرکتی" استفاده می شود که در آنها به معنای سیستم های اطلاعات خودکار واقعی اشیاء اقتصادی است.

سیستم اطلاعات خودکار (AIS) ترکیبی از انواع مختلف پشتیبانی و همچنین متخصصانی است که برای خودکارسازی پردازش اطلاعات حسابداری و تحلیلی طراحی شده اند. به عنوان یک قاعده، انواع پشتیبانی برای سیستم های مختلف از نظر ترکیب همگن هستند، که اجرای اصل سازگاری سیستم ها را در جریان عملکرد آنها ممکن می سازد. در فرآیند مطالعه AIS به عنوان یک سیستم پیچیده، لازم است که قطعات و عناصر جداگانه را جدا کرده و ویژگی های استفاده از آنها را در مراحل ایجاد و بهره برداری در نظر بگیریم.

سیستم‌های اطلاعات شرکتی تکاملی از سیستم‌ها برای گروه‌های کاری هستند، آنها بر شرکت‌های بزرگ متمرکز هستند و می‌توانند از گره‌ها یا شبکه‌های پراکنده جغرافیایی پشتیبانی کنند. اساساً ساختار سلسله مراتبی از چندین سطح دارند. چنین سیستم هایی با معماری مشتری-سرور با تخصص سرورها یا معماری چند لایه مشخص می شوند. هنگام توسعه چنین سیستم هایی، می توان از همان سرورهای پایگاه داده مانند هنگام توسعه سیستم های اطلاعات گروهی استفاده کرد. با این حال، در سیستم های اطلاعاتی بزرگ، رایج ترین سرورها Oracle، DB2 و Microsoft SQL Server هستند.

برای سیستم های گروهی و شرکتی، الزامات مربوط به قابلیت اطمینان عملیات و ایمنی داده ها به طور قابل توجهی افزایش می یابد. این ویژگی ها با حفظ داده ها، مرجع و یکپارچگی تراکنش در سرورهای پایگاه داده حفظ می شوند.

طبقه بندی بر اساس دامنه

با توجه به دامنه کاربرد، سیستم های اطلاعاتی معمولاً به چهار گروه تقسیم می شوند:

* سیستم های پردازش تراکنش؛

* سیستم های تصمیم گیری؛

* اطلاعات و سیستم های مرجع؛

* سیستم های اطلاعات اداری

کتابشناسی - فهرست کتب

1. Agaltsov، V.P. پایگاه داده. در 2 جلد V. 2. پایگاه داده های توزیع شده و از راه دور: کتاب درسی / V.P. آگالتسف. - M .: ID FORUM، NITs INFRA-M، 2013.

2. Golitsyna، O. L. پایگاه داده: کتاب درسی / O.L. گلیتسینا، N.V. ماکسیموف، I.I. پوپوف - M .: انجمن، 2012.

3. کارپووا، آی.پ. پایگاه داده: کتاب درسی / I.P. کارپوف - SPb .: پیتر، 2013.

4. کیریلف، V.V. مقدمه ای بر پایگاه داده های رابطه ای مقدمه ای بر پایگاه های داده رابطه ای. کریلوف، جی.یو. گروموف - SPb.: BHV-Petersburg، 2012.

5. پیروگوف، وی.یو. سیستم های اطلاعاتی و پایگاه های داده: سازمان و طراحی: کتاب درسی / V.Yu. پیروگوف - SPb.: BHV-Petersburg، 2009.

6. گ.ن. فدوروف. سیستم های اطلاعاتی. - M .: آکادمی، 2013.

7. A.E. ساتونینا، L.A. سیسووا. مدیریت پروژه سیستم اطلاعات شرکتی شرکت. - M.: امور مالی و آمار، Infra-M، 2009.

ارسال شده در Allbest.ru

...

اسناد مشابه

ماهیت و ویژگی های انواع مدل های داده: سلسله مراتبی، شبکه ای و رابطه ای. مفاهیم اساسی مدل داده های رابطه ای. ویژگی ها، طرح ارتباط پایگاه داده. شرایط یکپارچگی داده ها روابط بین جداول درک کلی از مدل داده

مقاله ترم، اضافه شده در 2011/01/29


سیستم های اطلاعاتی شرکت ها و پایگاه های داده، استفاده از آنها برای بهبود و اشکال زدایی کسب و کار. طبقه بندی سیستم های اطلاعات شرکت ها سیستم های اطلاعاتی کلاس OLTP پردازش تحلیلی سریع

مقاله ترم اضافه شد 19/01/2011


پایگاه های داده با فایل های دو بعدی و سیستم های مدیریت پایگاه داده رابطه ای (DBMS). ایجاد پایگاه داده و پردازش پرس و جوها برای آنها با استفاده از DBMS. انواع اصلی پایگاه های داده مفاهیم اساسی پایگاه های داده رابطه ای ویژگی های اساسی روابط

چکیده، اضافه شده در 2010/12/20


مفهوم سیستم پایگاه داده مدل رابطه ای و ویژگی های آن یکپارچگی در مدل رابطه ای جبر رابطه ای مسائل طراحی پایگاه داده اشکال عادی روابط طراحی پایگاه داده به روش entity-relationship. نمودارهای ER زبان SQL.

دوره سخنرانی اضافه شده در 10/03/2008


یک ساختار منطقی تعریف شده از داده ها که در یک پایگاه داده ذخیره می شود. مدل های داده های پایه عناصر مدل داده های رابطه ای نمونه ای از استفاده از کلیدهای خارجی. الزامات اساسی برای رابطه مدل داده های رابطه ای.

ارائه اضافه شده در 10/14/2013


پایگاه های داده و کاربرد آنها در محاسبات ویژگی ها و واحد سازنده اصلی مدل داده شبکه. مدل سلسله مراتبی، اشیاء حوزه موضوعی. مدل رابطه ای، مشاهده آن، ارائه داده ها به صورت جدولی.

چکیده، اضافه شده در 1390/12/19


انواع و عملکردهای سیستم مدیریت پایگاه داده مایکروسافت اکسس. مدل سلسله مراتبی، شبکه ای، رابطه ای برای توصیف پایگاه های داده. مفاهیم اساسی جدول پایگاه داده ویژگی های ایجاد اشیاء پایگاه داده، فرم های اساسی. دسترسی به اینترنت در Access.

تست، اضافه شده در 01/08/2011


سیستم های مدیریت پایگاه داده مدرن (DBMS). تجزیه و تحلیل مدل داده سلسله مراتبی. مدل داده های رابطه ای مدل داده پس رابطه ای به عنوان یک مدل رابطه ای توسعه یافته که محدودیت تقسیم ناپذیری داده های ذخیره شده در رکوردهای جدول را حذف می کند.

کار علمی، اضافه شده 06/08/2010


مدل های داده در مدیریت پایگاه داده مدل های داده های مفهومی نقش پایگاه های اطلاعاتی در سیستم های اطلاعاتی. مدل داده های رابطه ای تعریف حوزه موضوعی ساخت مدل پایگاه داده برای سیستم اطلاعاتی «حیوانات خانگی».

مقاله ترم، اضافه شده در 2011/04/19


مدل اطلاعات در Access به عنوان نوعی جایگزین ساده شده برای یک شی یا سیستم واقعی. ساختارهای اساسی که سازماندهی داده ها و روابط بین آنها را تعیین می کند. یک نوع رابطه ای از سازماندهی داده ها نمونه ای از پایگاه داده در مالیات.

مدل های داده های صنعت

هدف اصلی مدل ها تسهیل جهت گیری در فضای داده و کمک به برجسته سازی جزئیاتی است که برای توسعه کسب و کار مهم هستند. در محیط امروزی، برای یک کسب و کار موفق، داشتن درک روشنی از پیوندهای بین اجزای مختلف و داشتن ایده خوبی از تصویر کلی سازمان ضروری است. شناسایی کلیه جزئیات و روابط با استفاده از مدل ها امکان استفاده بهینه از زمان و ابزار را برای سازماندهی کار شرکت فراهم می کند.

مدل‌های داده، مدل‌های انتزاعی هستند که نحوه ارائه و دسترسی به داده‌ها را توصیف می‌کنند. مدل های داده اقلام داده و روابط بین آنها را در یک منطقه خاص تعریف می کنند. مدل داده یک ابزار ناوبری برای مشاغل و متخصصان فناوری اطلاعات است که از مجموعه خاصی از نمادها و کلمات برای توضیح دقیق طبقه خاصی از اطلاعات دنیای واقعی استفاده می کند. این امکان برقراری ارتباط بهتر در سازمان را فراهم می کند و در نتیجه یک محیط کاربردی انعطاف پذیرتر و پایدارتر ایجاد می کند.

مدل داده به طور منحصربه‌فردی معنای داده‌ها را تعریف می‌کند، که در این مورد، داده‌های ساخت‌یافته است (برخلاف داده‌های بدون ساختار مانند، برای مثال، یک تصویر، فایل باینری، یا متن، که در آن معنی می‌تواند مبهم باشد).

به عنوان یک قاعده، مدل های یک سطح بالاتر (و از نظر محتوا کلی تر) و یک پایین تر (به ترتیب، با جزئیات بیشتر) متمایز می شوند. سطح بالایی از مدل سازی به اصطلاح است مدل های داده های مفهومی(مدل های داده مفهومی)، که کلی ترین تصویر را از عملکرد یک شرکت یا سازمان ارائه می دهد. مدل مفهومی شامل مفاهیم اصلی یا حوزه های موضوعی است که برای عملکرد سازمان حیاتی هستند. معمولا تعداد آنها از 12-15 تجاوز نمی کند. چنین مدلی کلاس‌های موجودیت‌هایی را که برای سازمان مهم هستند (اشیاء تجاری)، ویژگی‌های آنها (ویژگی‌ها) و ارتباط بین جفت‌های این کلاس‌ها (یعنی روابط) را توصیف می‌کند. از آنجایی که اصطلاحات در مدل‌سازی کسب‌وکار هنوز به سرانجام نرسیده است، در منابع مختلف انگلیسی زبان، مدل‌های داده مفهومی را می‌توان مدل حوزه موضوعی (که می‌توان به عنوان مدل‌های دامنه ترجمه کرد) یا مدل داده سازمانی موضوع (مدل‌های داده شرکتی موضوعی) نامید. ).

سطح سلسله مراتبی بعدی است مدل های داده های منطقی(مدل های داده های منطقی). آنها را می توان مدل های داده سازمانی یا مدل های تجاری نیز نامید. این مدل‌ها شامل ساختارهای داده، ویژگی‌ها و قوانین تجاری آن‌ها هستند و اطلاعات مورد استفاده یک شرکت را از منظر تجاری نشان می‌دهند. در چنین مدلی، داده ها در قالب موجودیت ها و روابط بین آنها سازماندهی می شوند. مدل منطقی داده ها را به گونه ای ارائه می کند که درک آن را برای کاربران تجاری آسان می کند. در یک مدل منطقی، یک فرهنگ لغت داده را می توان متمایز کرد - فهرستی از همه موجودیت ها با تعاریف دقیق آنها، که به دسته های مختلف کاربران اجازه می دهد تا درک مشترکی از تمام جریان های ورودی و خروجی اطلاعات مدل داشته باشند. سطح پایین‌تر بعدی مدل‌سازی، پیاده‌سازی فیزیکی مدل منطقی با استفاده از نرم‌افزارهای خاص و پلت‌فرم‌های فنی است.

مدل منطقی شامل یک تصمیم تجاری شرکتی با جزئیات است که معمولاً به شکل یک مدل عادی شده است. عادی سازی فرآیندی است که تضمین می کند هر آیتم داده در یک مدل تنها یک مقدار دارد و به طور کامل و منحصر به فرد به کلید اصلی وابسته است. اقلام داده با توجه به هویت منحصر به فردشان به گروه هایی سازماندهی می شوند. قوانین تجاری حاکم بر اقلام داده باید به طور کامل در مدل نرمال شده با اعتبار و اعتبارسنجی قبلی گنجانده شوند. به عنوان مثال، یک آیتم داده مانند نام مشتری احتمالاً به نام و نام خانوادگی تقسیم می شود و با سایر موارد داده مرتبط در یک موجودیت مشتری با شناسه مشتری کلید اصلی گروه بندی می شود.

مدل داده‌های منطقی مستقل از فناوری‌های کاربردی مانند پایگاه‌های داده، فناوری‌های شبکه یا ابزارهای گزارش‌دهی و ابزارهای پیاده‌سازی فیزیکی آن‌ها است. در یک سازمان فقط یک مدل داده سازمانی می تواند وجود داشته باشد. مدل‌های منطقی معمولاً شامل هزاران موجودیت، رابطه و ویژگی هستند. به عنوان مثال، یک مدل داده برای یک موسسه مالی یا شرکت مخابراتی می تواند شامل حدود 3000 مفهوم صنعتی باشد.

تمایز بین مدل داده های منطقی و معنایی مهم است. مدل داده های منطقی یک راه حل تجاری سازمانی را نشان می دهد و مدل داده معنایی یک راه حل تجاری کاربردی را نشان می دهد. همان مدل داده منطقی شرکتی را می توان با استفاده از مدل های معنایی مختلف پیاده سازی کرد، به عنوان مثال. مدل‌های معنایی را می‌توان به‌عنوان سطح بعدی مدل‌سازی در نظر گرفت که به مدل‌های فیزیکی نزدیک می‌شود. علاوه بر این، هر یک از این مدل‌ها «برشی» جداگانه از مدل داده‌های شرکتی را مطابق با الزامات برنامه‌های مختلف نشان می‌دهند. به عنوان مثال، در مدل داده های منطقی شرکتی، موجودیت Client به طور کامل نرمال می شود و در مدل معنایی برای داده های مارت، می توان آن را به عنوان یک ساختار چند بعدی نشان داد.

یک شرکت می تواند دو راه برای ایجاد یک مدل داده منطقی شرکتی داشته باشد: آن را به طور مستقل بسازد یا از یک مدل آماده استفاده کند. مدل صنعت(مدل داده های منطقی صنعت). در این مورد، تفاوت در اصطلاحات تنها رویکردهای متفاوتی را برای ساخت مدل منطقی یکسان نشان می دهد. در صورتی که یک شرکت به طور مستقل مدل داده های منطقی خود را توسعه و پیاده سازی کند، معمولاً چنین مدلی به سادگی یک مدل منطقی شرکتی نامیده می شود. اگر سازمانی تصمیم بگیرد از یک محصول آماده از یک تامین کننده حرفه ای استفاده کند، آنگاه می توانیم در مورد مدل داده های منطقی صنعت صحبت کنیم. مدل دوم یک مدل داده منطقی آماده است که عملکرد یک صنعت خاص را با درجه بالایی از دقت منعکس می کند. یک مدل منطقی صنعت، نمای یک دامنه خاص و یکپارچه از تمام اطلاعاتی است که باید در انبار داده سازمانی وجود داشته باشد تا به سوالات استراتژیک و تاکتیکی تجاری پاسخ دهد. مانند هر مدل داده منطقی، مدل صنعتی مستقل از تصمیمات کاربردی است. همچنین شامل داده های مشتق شده یا سایر محاسبات برای بازیابی سریعتر داده نمی شود. به عنوان یک قاعده، بیشتر ساختارهای منطقی چنین مدلی به خوبی در اجرای فیزیکی مؤثر آن تجسم یافته است. چنین مدل هایی توسط بسیاری از تامین کنندگان برای طیف گسترده ای از فعالیت ها توسعه یافته است: امور مالی، تولید، گردشگری، مراقبت های بهداشتی، بیمه و غیره.

یک مدل داده منطقی صنعت حاوی اطلاعاتی است که در صنعت مشترک است و بنابراین نمی تواند راه حل جامعی برای یک شرکت باشد. اکثر شرکت ها باید با افزودن اقلام داده و گسترش تعاریف، مدل را به طور متوسط ​​25 درصد رشد دهند. مدل های خارج از جعبه فقط حاوی عناصر داده های کلیدی هستند و بقیه عناصر باید در حین نصب مدل در شرکت به اشیاء تجاری مربوطه اضافه شوند.

مدل های داده های منطقی صنعت حاوی مقدار قابل توجهی انتزاع هستند. انتزاع ها به معنای اتحاد مفاهیم مشابه تحت نام های مشترکی مانند رویداد یا شرکت کننده است. این انعطاف پذیری و یکنواختی را به مدل های صنعتی اضافه می کند. بنابراین، مفهوم رویداد برای همه صنایع قابل اجرا است.

استیو هابرمن، متخصص هوش تجاری، پنج عامل را شناسایی می‌کند که باید هنگام تصمیم‌گیری برای دستیابی به مدل داده‌های صنعت در نظر گرفته شود. اولین مورد، زمان و پول مورد نیاز برای ساخت مدل است. اگر سازمانی نیاز به دستیابی سریع به نتایج داشته باشد، مدل صنعت سودمند خواهد بود. استفاده از یک مدل صنعتی ممکن است بلافاصله تصویری از کل سازمان ارائه نکند، اما می تواند مقدار قابل توجهی در زمان صرفه جویی کند. به‌جای مدل‌سازی، زمان صرف پیوند ساختارهای موجود به مدل صنعت و بحث در مورد چگونگی بهترین سفارشی‌سازی آن با نیازهای سازمان می‌شود (مثلاً کدام تعاریف باید تغییر کند و کدام اقلام داده باید اضافه شود).

عامل دوم، زمان و پول مورد نیاز برای حفظ عملکرد خوب مدل است. اگر مدل داده های سازمانی بخشی از روشی نباشد که به شما امکان می دهد انطباق با دقت و مطابقت آن با استانداردهای مدرن را نظارت کنید، چنین مدلی خیلی سریع منسوخ می شود. مدل داده های صنعت می تواند از وقوع این خطر جلوگیری کند زیرا با منابع خارجی به روز می شود. البته تغییراتی که در داخل سازمان رخ می دهد باید توسط خود شرکت در مدل منعکس شود، اما تغییرات صنعت توسط تامین کننده آن در مدل بازتولید می شود.

عامل سوم تجربه در ارزیابی ریسک و مدل سازی است. ایجاد یک مدل داده شرکتی به منابع واجد شرایط هم از سوی کسب و کار و هم از کارکنان فناوری اطلاعات نیاز دارد. به عنوان یک قاعده، مدیران به خوبی از کار سازمان به عنوان یک کل یا فعالیت های یک بخش خاص آگاه هستند. تعداد کمی از آنها دانش گسترده (در سطح شرکت) و عمیق (در داخل بخش) از تجارت خود دارند. اکثر مدیران معمولا فقط یک حوزه را به خوبی می شناسند. بنابراین، برای به دست آوردن تصویر کلی شرکت، منابع تجاری قابل توجهی مورد نیاز است. این همچنین باعث افزایش تقاضا برای کارکنان فناوری اطلاعات می شود. هرچه منابع تجاری بیشتری برای ایجاد و آزمایش یک مدل مورد نیاز باشد، تحلیلگران با تجربه بیشتری باید داشته باشند. آنها نه تنها باید بدانند که چگونه اطلاعات را از کارکنان کسب و کار دریافت کنند، بلکه بتوانند دیدگاه مشترکی را در زمینه های بحث برانگیز پیدا کنند و بتوانند همه این اطلاعات را به صورت یکپارچه ارائه دهند. شخصی که مدل را ایجاد می کند (در بسیاری از موارد همان تحلیلگر) باید مهارت های مدل سازی خوبی داشته باشد. ساخت مدل‌های منطقی سازمانی مستلزم مدل‌سازی «برای آینده» و توانایی تبدیل واقعی تجارت پیچیده «به مربع و خطوط» است.

از سوی دیگر، مدل صنعت اجازه می دهد تا برای تخصص خارجی. مدل‌های منطقی خاص صنعت با استفاده از روش‌های مدل‌سازی اثبات‌شده و تیم‌هایی متشکل از متخصصان باتجربه ساخته می‌شوند تا از مشکلات رایج و پرهزینه‌ای که ممکن است هنگام توسعه مدل‌های داده سازمانی در یک سازمان ایجاد شود، جلوگیری کنند.

عامل چهارم، زیرساخت های کاربردی موجود و روابط تامین کننده است. اگر سازمانی در حال حاضر از ابزارهای زیادی از یک تامین کننده استفاده می کند و با او ارتباط برقرار کرده است، پس منطقی است که مدل صنعتی از او سفارش داده شود. این مدل می تواند آزادانه با سایر محصولات همان تامین کننده کار کند.

عامل پنجم تبادل اطلاعات درون صنعت است. اگر یک شرکت نیاز به برقراری ارتباط با سایر سازمان های فعال در همان زمینه داشته باشد، مدل صنعت در این شرایط می تواند بسیار مفید باشد. سازمان ها در همان صنعت از اجزای ساختاری و اصطلاحات مشابه استفاده می کنند. امروزه در بیشتر صنایع، شرکت ها برای انجام موفقیت آمیز تجارت مجبور به تبادل داده ها هستند.

موثرترین مدل های صنعتی ارائه شده توسط تامین کنندگان حرفه ای هستند. بهره وری بالای استفاده از آنها به دلیل سطح قابل توجه جزئیات و دقت این مدل ها به دست می آید. آنها معمولاً حاوی بسیاری از ویژگی های داده هستند. علاوه بر این، سازندگان این مدل‌ها نه تنها تجربه مدل‌سازی گسترده‌ای دارند، بلکه در ساخت مدل‌های یک صنعت خاص نیز به خوبی تبحر دارند.

مدل‌های داده‌های صنعت، یک دیدگاه واحد و یکپارچه از اطلاعات کسب‌وکارشان به شرکت‌ها ارائه می‌کند. بسیاری از شرکت‌ها برای یکپارچه‌سازی داده‌های خود مشکل دارند، اگرچه این پیش‌نیاز برای اکثر پروژه‌های سازمانی است. بر اساس مطالعه‌ای که توسط موسسه انبار داده (TDWI) انجام شده است، بیش از 69 درصد از سازمان‌های مورد بررسی دریافتند که یکپارچگی مانع مهمی برای پذیرش برنامه‌های کاربردی جدید است. برعکس، اجرای یکپارچه سازی داده ها درآمد ملموسی را برای شرکت ایجاد می کند.

مدل داده‌های صنعت، علاوه بر پیوند به سیستم‌های موجود، مزایای بزرگی را برای پروژه‌های سازمانی مانند برنامه‌ریزی منابع سازمانی (ERP)، مدیریت داده‌های اصلی، هوش تجاری، بهبود کیفیت داده‌ها و توسعه کارکنان فراهم می‌کند.

بنابراین، مدل‌های داده‌های منطقی صنعت ابزار مؤثری برای یکپارچه‌سازی داده‌ها و به‌دست‌آوردن دیدی کل‌نگر از کسب‌وکار هستند. به نظر می رسد استفاده از مدل های منطقی گامی ضروری در جهت ایجاد انبارهای داده شرکتی باشد.

انتشارات

1. استیو هابرمن استفاده از مدل داده های منطقی صنعت به عنوان مدل داده های سازمانی شما.
2. کلودیا ایمهوف ردیابی سریع پروژه های انبارداری داده و هوش تجاری از طریق مدل سازی هوشمند داده ها

هدف از سخنرانی

پس از مطالعه مطالب این سخنرانی خواهید دانست:

• چی مدل داده های سازمانی ;
• نحوه تبدیل مدل داده های سازمانیدر مدل انبار داده؛
• عناصر اصلی مدل داده های شرکتی ;
• لایه های ارائه مدل داده های شرکتی ;
• الگوریتمی برای تبدیل یک مدل داده سازمانی به یک مدل انبار داده چند بعدی ;

و یاد بگیرید که:

• توسعه مدل های انبار داده بر اساس مدل داده های شرکتیسازمان های؛
• طراحی یک طرحواره ستاره با استفاده از ابزار CASE.
• جداول پارتیشن مدل چند بعدیبا استفاده از ابزار CASE

مدل داده های سازمانی

معرفی

هسته هر HD مدل داده آن است. بدون مدل داده، سازماندهی داده ها در HD بسیار دشوار خواهد بود. بنابراین، توسعه دهندگان سی دی باید زمان و تلاش خود را برای توسعه چنین مدلی صرف کنند. توسعه مدل HD بر دوش طراح HD است.

در مقایسه با طراحی سیستم‌های OLTP، روش طراحی CD دارای تعدادی ویژگی متمایز مرتبط با جهت‌گیری ساختارهای داده ذخیره‌سازی برای حل مشکلات تجزیه و تحلیل و پشتیبانی اطلاعات فرآیند تصمیم‌گیری است. مدل داده های HD باید دقیقاً برای این مشکلات راه حل مؤثری ارائه دهد.

نقطه شروع در طراحی سی دی می تواند به اصطلاح باشد مدل داده های سازمانی(مدل داده های شرکتی یا مدل داده های سازمانی، EDM)، که در فرآیند طراحی سیستم های OLTP یک سازمان ایجاد می شود. هنگام طراحی مدل داده های شرکتیمعمولاً تلاش می شود تا ساختار داده ای بر اساس عملیات تجاری ایجاد شود که تمام نیازهای اطلاعاتی یک سازمان را جمع آوری و ترکیب کند.

بدین ترتیب، مدل داده های سازمانیحاوی اطلاعات لازم برای ساخت مدل سی دی است. بنابراین در مرحله اول در صورت وجود چنین مدلی در سازمان، طراح HD می تواند طراحی HD را با حل مشکل تبدیل شروع کند مدل داده های شرکتی به مدل HD.

مدل داده های سازمانی

چگونه می توان مشکل تحول را حل کرد مدل داده های شرکتیبه مدل HD؟ برای حل این مشکل، باید این مدل را داشته باشید، یعنی. مدل داده های شرکتیباید ساخته شود و ثبت شده... و باید بفهمی چیاز این مدل و چگونهباید به مدل HD تبدیل شود.

اجازه دهید از دیدگاه یک طراح سی دی این مفهوم را روشن کنیم مدل داده های شرکتی. زیر مدل داده های شرکتیدرک یک توصیف ساختاریافته و چند سطحی از حوزه های موضوعی سازمان، ساختارهای داده حوزه موضوعی، فرآیندهای کسب و کار و رویه های تجاری، جریان داده های سازمانی، نمودارهای حالت، ماتریس های فرآیند داده و سایر نمایش های مدلی که در فعالیت های سازمان استفاده می شود. بنابراین، به معنای وسیع کلمه، مدل داده های سازمانیمجموعه‌ای از مدل‌های سطوح مختلف است که فعالیت‌های یک سازمان را مشخص می‌کند (مدل در سطحی انتزاعی). محتوا مدل شرکتیبه طور مستقیم به این بستگی دارد که چه ساختارهای مدلی در یک سازمان معین در آن گنجانده شده است.

عناصر اصلی مدل داده های شرکتیهستند:

• شرح حوزه های موضوعی سازمان (تعریف حوزه های فعالیت)؛
• روابط بین حوزه های موضوعی تعریف شده در بالا؛
• مدل داده های اطلاعاتی (ERD-model یا Enity-Raction model).
• توضیحات برای هر حوزه موضوعی:
  • کلیدهای نهاد؛
  • ویژگی های موجودیت;
  • انواع فرعی و سوپرتیپ;
  • روابط بین نهادها؛
  • گروه بندی صفات؛
  • روابط بین حوزه های موضوعی؛
• مدل عملکردی یا فرآیند کسب و کار؛
• نمودارهای جریان داده؛
• نمودارهای حالت؛
• مدل های دیگر

بدین ترتیب، مدل داده های سازمانیشامل موجودیت ها، ویژگی ها و روابطی است که نشان دهنده نیازهای اطلاعاتی یک سازمان است. در شکل 16.1 عناصر اصلی را نشان می دهد مدل داده های شرکتی.

سطوح ارائه مدل داده سازمانی

مدل داده های سازمانیبر اساس حوزه‌های موضوعی تقسیم‌بندی می‌شوند، که نشان‌دهنده گروه‌هایی از نهادهای مرتبط با حمایت از نیازهای تجاری خاص است. برخی از حوزه‌های موضوعی ممکن است عملکردهای تجاری خاصی مانند مدیریت قرارداد را پوشش دهند، در حالی که برخی دیگر ممکن است شامل نهادهایی باشند که محصولات یا خدمات را توصیف می‌کنند.

هر مدل منطقی باید با دامنه موجود مطابقت داشته باشد مدل داده های شرکتی... اگر مدل منطقی این شرط را برآورده نمی کند، باید یک مدل دامنه به آن اضافه شود.

مدل داده های سازمانیمعمولاً چندین سطح ارائه دارد. در حقیقت سطح بالا(سطح بالا) مدل داده های شرکتیشرحی از حوزه های موضوعی اصلی سازمان و روابط آنها در سطح نهاد وجود دارد. در شکل 16.2 یک قطعه است مدل داده های شرکتیسطح بالا.

برنج. 16.2.

نمودار نشان داده شده در شکل چهار حوزه موضوعی را نشان می دهد: "خریدار" ( مشتری)، "بررسی" ( حساب)، "سفارش" ( سفارش) و "محصول" ( تولید - محصول). به عنوان یک قاعده، فقط اتصالات مستقیمبین حوزه های موضوعی، که به عنوان مثال، این واقعیت را ثبت می کند: خریدار فاکتور سفارش کالا را پرداخت می کند. جزئیات و روابط غیر مستقیم در این سطح مدل شرکتینمایش داده نشده.

در مورد بعدی، سطح میانی(سطح متوسط) مدل داده های شرکتیاطلاعات دقیق در مورد اشیاء مناطق موضوع نشان داده شده است، یعنی کلیدها و ویژگی های موجودیت، روابط آنها، زیرگونه ها و ابرگونه ها و غیره. برای هر دامنه از مدل سطح بالا، یک مدل سطح متوسط ​​وجود دارد. در شکل 16.3 سطح میانی ارائه را نشان می دهد مدل شرکتیبرای بخشی از منطقه موضوعی "Order".

از انجیر 16.3 می توان مشاهده کرد که منطقه موضوع "Order" ( سفارش) شامل چندین موجودیت است که از طریق ویژگی های آنها و روابط بین آنها تعریف شده اند. مدل ارائه شده به شما این امکان را می دهد که به سوالاتی مانند تاریخ سفارش، چه کسی سفارش، چه کسی سفارش را ارسال کرده، چه کسی سفارش را دریافت کرده و تعدادی دیگر پاسخ دهید. از نمودار بالا می توان دریافت که در این سازمان دو نوع سفارش وجود دارد - سفارشات برای ارتقا ( تجاری) و سفارشات خرده فروشی ( خرده فروشی).

توجه کنید که مدل داده های سازمانیمی تواند نمایانگر جنبه های مختلف فعالیت های سازمان و با درجات مختلف از جزئیات و کامل باشد. اگر مدل شرکتینشان دهنده تمام جنبه های فعالیت سازمان است، همچنین نامیده می شود مدل داده های سازمان(مدل داده های سازمانی).

از دیدگاه طراحی سی دی، عامل مهمی در تصمیم گیری برای ایجاد مدل سی دی از مدل داده های شرکتیدولت است کامل بودن مدل داده های شرکتی.

مدل داده های سازمانیسازمان دارای ویژگی تکاملی است، یعنی. به طور مداوم در حال توسعه و بهبود است. برخی از حوزه های موضوعی مدل داده های شرکتیممکن است به خوبی توسعه یافته باشد، برای برخی ممکن است کار هنوز شروع نشده باشد. اگر قطعه ای از ناحیه موضوع در آن کار نشده باشد مدل داده های شرکتی، پس راهی برای استفاده از این مدل به عنوان نقطه شروع برای طراحی سی دی وجود ندارد.

مدرک تکمیلی مدل شرکتیمی توان در طراحی سی دی به صورت زیر سطح بندی کرد. از آنجایی که فرآیند توسعه HD معمولاً از نظر زمان به مراحل متوالی تقسیم می شود، فرآیند طراحی آن را می توان با فرآیند تکمیلتوسعه قطعات فردی مدل داده های شرکتیسازمان های.

در کمترین لایه ارائه مدل داده های شرکتیاطلاعات در مورد ویژگی های فیزیکی اشیاء پایگاه داده مربوط به مدل داده های منطقیوسط لایه ارائه مدل داده های شرکتی.