Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Деректер архитектурасы – деректер жүйелерінде және ұйымдарда қандай деректер жиналатынын, қалай сақталынатынын, құрылатынын, біріктіріліп, қолданылатынын анықтайтын модельдер, саясаттар, ережелер және стандарттар жиынтығы. Деректер көбінесе кәсіпорын архитектурасының немесе шешімдер архитектурасының негізгі құрамдас бөліктерінің бірі болып табылады.
Data architecture consist of models, policies, rules, and standards that govern which data is collected and how it is stored, arranged, integrated, and put to use in data systems and in organizations. Data is usually one of several architecture domains that form the pillars of an enterprise architecture or solution architecture.
Физикалық деректер архитектурасы
Ақпараттық жүйенің физикалық дерек архитектурасы технологиялық жоспардың бір бөлігі болып табылады. Технологиялық жоспар дерек архитектурасының жобасын іске асыру үшін қолданылатын нақты, материалдық элементтерге бағытталған. Физикалық дерек архитектурасы дерекқоры архитектурасын қамтиды. Дерекқоры архитектурасы – жобаланған дерек архитектурасын қолдайтын нақты дерекқор технологиясының схемасы.
Physical data architecture of an information system is part of a technology plan. The technology plan is focused on the actual tangible elements to be used in the implementation of the data architecture design. Physical data architecture encompasses database architecture. Database architecture is a schema of the actual database technology that would support the designed data architecture.
Деректер архитектурасының элементтері
Деректер архитектурасының схемасын жобалау кезеңінде белгілі бір элементтер анықталуы тиіс. Мысалы, дерек ресурстарын басқару үшін құрылатын әкімшілік құрылым сипатталуы керек. Сондай-ақ, деректерді сақтауға қолданылатын әдістемелер анықталуы тиіс. Сонымен қатар, қолданылатын деректер базасы технологиясының сипаттамасы, сондай-ақ деректерді өңдеу процестерінің сипаттамасы жасалуы керек. Басқа жүйелер деректермен өзара әрекеттесуге арналған интерфейстерді жобалау, сондай-ақ ортақ дерек операцияларын қолдайтын инфрақұрылымды жобалау да маңызды (яғни, төтенше жағдайларға жауап беру процедуралары, деректерді импорттау, деректерді сақтау, деректерді сыртқа тасымалдау). Дұрыс іске асырылған деректер архитектурасының жобалауы болмаса, ортақ дерек операциялары әртүрлі тәсілдермен орындалуы мүмкін, бұл мұндай жүйелердегі дерек ағынын түсінуді және басқаруды қиындатады. Мұндай фрагментация қажетсіз, себебі ол шығындарды арттыруы және деректердің үзілуіне әкелуі мүмкін. Мұндай қиындықтар қарқынды өсіп келе жатқан кәсіпорындарда, сондай-ақ әртүрлі бизнес салаларына қызмет көрсететін кәсіпорындарда кездесуі мүмкін. Дұрыс орындалған деректер архитектурасы кезеңі ақпараттық жүйелерді жоспарлауда ұйымды ішкі және сыртқы ақпарат ағындарын нақтылауға және сипаттауға мәжбүр етеді. Бұл – ұйым бұрын назар аудармаған немесе уақыт бөлмеген үлгілер болуы мүмкін. Сондықтан осы кезеңде деректер архитектурасын талдау алдында байқалмаған ақпараттың жетіспеушілігін, бөлімдер арасындағы және ұйымдық жүйелер арасындағы байланыс үзілуін анықтауға болады.
Certain elements must be defined during the design phase of the data architecture schema. For example, an administrative structure that is to be established in order to manage the data resources must be described. Also, the methodologies that are to be employed to store the data must be defined. In addition, a description of the database technology to be employed must be generated, as well as a description of the processes that are to manipulate the data. It is also important to design interfaces to the data by other systems, as well as a design for the infrastructure that is to support common data operations (i. e. emergency procedures, data imports, data backups, external transfers of data). Without the guidance of a properly implemented data architecture design, common data operations might be implemented in different ways, rendering it difficult to understand and control the flow of data within such systems. This sort of fragmentation is undesirable due to the potential increased cost and the data disconnects involved. These sorts of difficulties may be encountered with rapidly growing enterprises and also enterprises that service different lines of business. Properly executed, the data architecture phase of information system planning forces an organization to specify and describe both internal and external information flows. These are patterns that the organization may not have previously taken the time to conceptualize. It is therefore possible at this stage to identify costly information shortfalls, disconnects between departments, and disconnects between organizational systems that may not have been evident before the data architecture analysis.
Шектеулер мен әсерлер
Деректер архитектурасының жобалауына әр түрлі шектеулер мен ықпалдар әсер етеді. Оларға кәсіпорынның талаптары, технологиялық драйверлер, экономика, бизнес-саясат және деректерді өңдеу қажеттіліктері жатады. Кәсіпорынның талаптары. Бұларға әдетте жүйенің экономикалық және тиімді кеңейтілуі, қанағаттанарлық өнімділік деңгейі (әсіресе жүйеге қол жеткізу жылдамдығы), транзакциялардың сенімділігі және деректерді түсінікті басқару сияқты элементтер кіреді. Сонымен қатар, транзакциялық жазбалар мен кескіндер сияқты бастапқы деректерді деректер қоймалары сияқты мүмкіндіктер арқылы пайдалы ақпарат түрлеріне айналдыру да кең таралған ұйымдық талап болып табылады, себебі бұл басқару шешімдерін қабылдауға және басқа ұйымдық процестерге көмектеседі. Архитектуралық тәсілдердің бірі – транзакциялық деректерді басқару мен (негізгі) анықтамалық деректерді бөлу. Тағы бірі – деректерді жинау жүйелерін деректерді іздеу жүйелерінен бөлу (деректер қоймасында жасалғандай). Технологиялық драйверлер. Бұлар әдетте аяқталған деректер архитектурасы мен деректер базасы архитектурасының жобаларымен ұсынылады. Сонымен қатар, кейбір технологиялық драйверлер қолданыстағы ұйымдық интеграциялық аялар мен стандарттардан, ұйымдық экономикадан және қолданыстағы сайт ресурстарынан (мысалы, бұрын сатып алынған бағдарламалық қамтамасы лицензиясы) туындайды. Көп жағдайда бірнеше ескі жүйелерді интеграциялау деректерді виртуализациялау технологияларын қолдануды қажет етеді. Экономика. Бұл деректер архитектурасы кезеңінде қарастырылуы тиіс маңызды факторлардың бірі. Кейбір шешімдер қағида бойынша оңтайлы болғанымен, олардың құнына байланысты іске асыруға мүмкіншілігі болмауы мүмкін. Бизнес айналымы, пайыздық ставкалар, нарық жағдайы және заңнамалық талаптар сияқты сыртқы факторлар деректер архитектурасына қатысты шешімдерге әсер етуі мүмкін. Бизнес-саясат. Деректер архитектурасының жобалауын басқаратын бизнес-саясатқа ішкі ұйымдық саясат, реттеуші органдардың ережелері, кәсіби стандарттар және қолданылатын мемлекеттік заңдар кіреді, олар қолданылатын агенттікке байланысты өзгеруі мүмкін. Бұл саясаттар мен ережелер кәсіпорынның деректерін қалай өңдеуге ниеттенгенін сипаттайды. Деректерді өңдеу қажеттіліктері. Оларға жоғары көлемде орындалатын дәл және қайталанатын транзакциялар, басқару ақпараттық жүйелерін (және деректерді талдау мүмкіндігін) қолдау үшін деректерді сақтау, мерзімді есеп беру, қажеттілікке қарай ұйымдық бастамаларды қолдау (мысалы, жылдық бюджеттер, жаңа өнімдерді әзірлеу) кіреді.
Various constraints and influences will have an effect on data architecture design. These include enterprise requirements, technology drivers, economics, business policies and data processing needs. Enterprise requirements These generally include such elements as economical and effective system expansion, acceptable performance levels (especially system access speed), transaction reliability, and transparent data management. In addition, the conversion of raw data such as transaction records and image files into more useful information forms through such features as data warehouses is also a common organizational requirement, since this enables managerial decision making and other organizational processes. One of the architecture techniques is the split between managing transaction data and (master) reference data. Another is splitting data capture systems from data retrieval systems (as done in a data warehouse). Technology drivers These are usually suggested by the completed data architecture and database architecture designs. In addition, some technology drivers will derive from existing organizational integration frameworks and standards, organizational economics, and existing site resources (e. g. previously purchased software licensing). In many cases, the integration of multiple legacy systems requires the use of data virtualization technologies. Economics These are also important factors that must be considered during the data architecture phase. It is possible that some solutions, while optimal in principle, may not be potential candidates due to their cost. External factors such as the business cycle, interest rates, market conditions, and legal considerations could all have an effect on decisions relevant to data architecture. Business policies Business policies that also drive data architecture design include internal organizational policies, rules of regulatory bodies, professional standards, and applicable governmental laws that can vary by applicable agency. These policies and rules describe the manner in which the enterprise wishes to process its data. Data processing needs These include accurate and reproducible transactions performed in high volumes, data warehousing for the support of management information systems (and potential data mining), repetitive periodic reporting, ad hoc reporting, and support of various organizational initiatives as required (i. e. annual budgets, new product development).