Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Деректер қоймасындағы фактілер мен өлшемдерді жіктеуге арналған құрылым – деректер қоймасындағы өлшем.
Structure that categorizes facts and measures in a data warehouse
a dimension in a data warehouse
Өлшем – пайдаланушыларға бизнес сұрақтарына жауап беруге мүмкіндік беру үшін фактілер мен өлшемдерді жіктейтін құрылым. Көбінесе адамдар, өнімдер, орын және уақыт өлшемдер ретінде қолданылады. (Ескертпе: Адамдар мен уақыт кейде өлшем ретінде модельденбейді.) Деректер қоймасында өлшемдер, ретсіз сандық өлшемдерге құрылымды таңбалау ақпаратын ұсынады. Өлшем – жеке, бір-бірімен қабаттаспайтын дерек элементтерінен тұратын дерек жиынтығы. Өлшемдердің негізгі функциялары үш түрлі: сүзгілеу, топтастыру және таңбалау. Бұл функциялар көбінесе «кесіп-түйіршіктеу» деп сипатталады. Деректер қоймасының кең таралған мысалы – сатуды өлшем ретінде, ал тұтынушы мен өнімді өлшемдер ретінде пайдалану. Әр сатылымда тұтынушы өнім сатып алады. Деректерді зерттеу тобынан басқа барлық тұтынушыларды алып тастау арқылы кесуге болады, содан кейін өнім бойынша топтастыру арқылы түйіршіктеуге болады. Өлшемдік дерек элементі – статистикадағы категориялық айнымалыға ұқсас. Әдетте деректер қоймасындағы өлшемдер бір немесе бірнеше иерархияға ішкі түрде ұйымдастырылады. «Күн» – бірнеше мүмкін иерархиясы бар кең таралған өлшем:
A dimension is a structure that categorizes facts and measures in order to enable users to answer business questions. Commonly used dimensions are people, products, place and time. (Note: People and time sometimes are not modeled as dimensions.) In a data warehouse, dimensions provide structured labeling information to otherwise unordered numeric measures. The dimension is a data set composed of individual, non overlapping data elements. The primary functions of dimensions are threefold: to provide filtering, grouping and labelling. These functions are often described as "slice and dice". A common data warehouse example involves sales as the measure, with customer and product as dimensions. In each sale a customer buys a product. The data can be sliced by removing all customers except for a group under study, and then diced by grouping by product. A dimensional data element is similar to a categorical variable in statistics. Typically dimensions in a data warehouse are organized internally into one or more hierarchies. "Date" is a common dimension, with several possible hierarchies:
«Күндер (топтастырылған) Айлар (топтастырылған) Жылдар»,
«Күндер (топтастырылған) Апталар (топтастырылған) Жылдар»
«Күндер (топтастырылған) Айлар (топтастырылған) Тоқсандар (топтастырылған) Жылдар»
және т.б.
"Days (are grouped into) Months (which are grouped into) Years",
"Days (are grouped into) Weeks (which are grouped into) Years"
"Days (are grouped into) Months (which are grouped into) Quarters (which are grouped into) Years"
etc.
Өлшемін баяу өзгерту
Баяу өзгеріп отыратын өлшем – уақыт өте ретсіз, бірақ баяу өзгеріп отыратын дерек атрибуттарының жиынтығы, мысалы, мекенжай немесе есім. Бұл атрибуттар уақыт ішінде өзгеріп, баяу өзгеріп отыратын өлшем ретінде біріктіріледі. Мұндай өлшемдер түрлеріне бөлінеді:
A slowly changing dimension is a set of data attributes that change slowly over a period of time rather than changing regularly e. g. address or name. These attributes can change over a period of time and that will get combined as a slowly changing dimension. These dimension can be classified in types:
0-түр (Түпнұсқаны сақтау): Атрибуттар ешқашан өзгермейді. Тарих жоқ. 1-түр (Жаңа мәнмен жабу): Атрибут үшін ескі мәндер жаңа мәндермен жабылады. Тарих жоқ. 2-түр (Жаңа қатар қосу): Жаңа мән үшін басталу күні/аяқталу күні немесе нұсқасы бар жаңа қатар құрылады. Бұл тарихты құрайды. 3-түр (Жаңа атрибут қосу): Жаңа мән үшін жаңа баған құрылады. Тарих тарихи деректерді сақтауға арналған бағандар санымен шектеледі. 4-түр (Тарих кестесін қосу): Бір кесте ағымдағы мәнді сақтайды, ал тарих екінші кестеде сақталады. 5-түр (1 + 4 біріктірілген тәсіл): 1-түр мен 4-түрдің комбинациясы. Тарих екінші тарих кестесі арқылы жасалады. 6-түр (1 + 2 + 3 біріктірілген тәсіл): 1-түр, 2-түр және 3-түрдің комбинациясы. Тарих жеке қатарлар мен атрибуттар арқылы құрылады. 7-түр (Гибридтік тәсіл): Суррогаттық және табиғи кілттер қолданылады.
Type 0 (Retain original): Attributes never change. No history. Type 1 (Overwrite): Old values are overwritten with new values for attribute. No history. Type 2 (Add new row): A new row is created with either a start date / end date or a version for a new value. This creates history. Type 3 (Add new attribute): A new column is created for a new value. History is limited to the number of columns designated for storing historical data. Type 4 (Add history table): One table keeps the current value, while the history is saved in a second table. Type 5 (Combined Approach 1 + 4): Combination of type 1 and type 4. History is created through a second history table. Type 6 (Combined Approach 1 + 2 + 3): Combination of type 1, type 2 and type 3. History is created through separate row and attributes. Type 7 (Hybrid Approach): Both surrogate and natural key are used.
Қалыпты өлшем
Қалыптасқан өлшем – бірнеше деректер кестесінде бірдей кілт мәнін пайдалана отырып, бірдей құрылымға, атрибуттарға, домендік мәндерге, анықтамалар мен түсініктерге физикалық сілтеме жасалған деректер атрибуттарының жиынтығы. Қалыптасқан өлшем көптеген фактілермен байланысты болады. Өлшемдер бір-біріне сәйкес келеді, егер олар толықтай бірдей болса (кілттерді қоса алғанда) немесе біреуі екіншісінің кіші жиыны болса. Ең маңыздысы, бір және де сол қалыптасқан өлшем(дер)ден алынған екі әртүрлі жауап жиынтығындағы қатар тақырыптары толық сәйкес келуі керек. Қалыптасқан өлшемдер ең ұсақ, егжей-тегжейлі өлшеммен толықтай бірдей немесе оның қатаң математикалық кіші жиыны болып табылады. Егер атрибуттар әртүрлі атаулармен белгіленген немесе әртүрлі мәндерді қамтитын болса, өлшем кестелері сәйкес келмейді. Қалыптасқан өлшемдердің түрлі нұсқалары бар. Ең қарапайым деңгейде, қалыптасқан өлшемдер олармен байланыстырылған барлық мүмкін фактілік кестелер үшін бірдей мағынаны білдіреді. Сату фактілеріне қосылған күндік өлшем кестесі, қор фактілеріне қосылған күндік өлшеммен толықтай сәйкес келеді.
A conformed dimension is a set of data attributes that have been physically referenced in multiple database tables using the same key value to refer to the same structure, attributes, domain values, definitions and concepts. A conformed dimension cuts across many facts. Dimensions are conformed when they are either exactly the same (including keys) or one is a proper subset of the other. Most important, the row headers produced in two different answer sets from the same conformed dimension(s) must be able to match perfectly.' Conformed dimensions are either identical or strict mathematical subsets of the most granular, detailed dimension. Dimension tables are not conformed if the attributes are labeled differently or contain different values. Conformed dimensions come in several different flavors. At the most basic level, conformed dimensions mean exactly the same thing with every possible fact table to which they are joined. The date dimension table connected to the sales facts is identical to the date dimension connected to the inventory facts.
Жүктілік өлшемі
Жәнкелді өлшем – әдетте төмен кардиналдылықтағы жалаушалар мен көрсеткіштердің ыңғайлы тобы. Абстрактілі өлшем құру арқылы осы жалаушалар мен көрсеткіштер фактілер кестесінен алынып, пайдалы өлшемдік құрылымға орналастырылады. Жәнкелді өлшем – фактілер кестесіне немесе қолданыстағы өлшем кестелерінің ешқайсысына жатпайтын атрибуттардан тұратын өлшем кестесі. Бұл атрибуттардың сипаты көбінесе мәтін немесе әртүрлі жалаулар, мысалы, жалпылама түсініктемелер немесе қарапайым «иә/жоқ» немесе «дұрыс/жалған» көрсеткіштері болады. Мұндай атрибуттар көбінесе бизнес-процестегі барлық анық өлшемдер анықталғаннан кейін қалады, сондықтан дизайнер осы атрибуттарды басқа өлшемдерге жатпайтын жерге қалай орналастыру керектігіне тап болады. Бір шешім – қалған атрибуттардың әрқайсысы үшін жаңа өлшем жасау, бірақ олардың сипатына байланысты көптеген жаңа өлшемдер жасау қажет болуы мүмкін, нәтижесінде көптеген сыртқы кілттері бар фактілер кестесі пайда болады. Дизайнер қалған атрибуттарды фактілер кестесінде қалдыруды да шеше алады, бірақ бұл, мысалы, атрибут ұзақ мәтіндік тізбе болса, кестедегі қатар ұзындығын қажетсіз түрде ұлғайтуы мүмкін. Бұл қиындыққа шешім – барлық атрибуттарды анықтап, оларды бір немесе бірнеше жәнкелді өлшемдерге орналастыру. Бір жәнкелді өлшемде бір-бірімен байланысы жоқ бірнеше «дұрыс/жалған» немесе «иә/жоқ» көрсеткіштері болуы мүмкін, сондықтан көрсеткіштерді сипаттамалық атрибутқа түрлендіру ыңғайлы. Мысалы, пакет келгені туралы көрсеткішті «иә» немесе «жоқ» деп көрсетудің орнына, оны жәнкелді өлшемде «келді» немесе «күтілуде» деп түрлендіруге болады. Дизайнер өлшем кестесін барлық комбинациялар қамтылған басқа көрсеткіштермен кездесетін барлық көрсеткіштерді қамтитындай етіп құруды таңдай алады. Бұл кесте үшін 2x қатар құрайды, мұнда x – көрсеткіштер саны. Бұл шешім дизайнер көптеген әртүрлі комбинацияларды күтетін және мүмкін комбинациялардың саны қанағаттанарлық деңгейде шектелген жағдайларда орынды. Егер көрсеткіштердің саны көп болса, яғни өте үлкен кесте пайда болса немесе дизайнер мүмкін болатын комбинациялардың аз ғана бөлігін күтсе, жаңа комбинациялар кездескен сайын жәнкелді өлшемде әр қатарды құру орындырақ болар еді. Кестелердің мөлшерін шектеу үшін әртүрлі көрсеткіштер арасындағы байланысқа байланысты бірнеше жәнкелді өлшемдерді пайдалану орынды болуы мүмкін. Жәнкелді өлшемдер фактілер кестесінен жалпылама түсініктемелер сияқты атрибуттарды орналастыру үшін де қолайлы. Мұндай атрибуттар клиент тапсырыс берген кездегі қосымша түсініктемелерден алынған деректерден тұруы мүмкін, сондықтан көп жағдайда бос болады. Сондықтан, жәнкелді өлшемде бос мәндерді білдіретін бір қатар болуы керек, ол бос түсініктемелермен қайтарылған әрбір қатар үшін фактілер кестесінде пайдаланылатын орынбасар кілт ретінде қолданылады.
A junk dimension is a convenient grouping of typically low cardinality flags and indicators. By creating an abstract dimension, these flags and indicators are removed from the fact table while placing them into a useful dimensional framework. A junk dimension is a dimension table consisting of attributes that do not belong in the fact table or in any of the existing dimension tables. The nature of these attributes is usually text or various flags, e. g. non generic comments or just simple yes/no or true/false indicators. These kinds of attributes are typically remaining when all the obvious dimensions in the business process have been identified and thus the designer is faced with the challenge of where to put these attributes that do not belong in the other dimensions. One solution is to create a new dimension for each of the remaining attributes, but due to their nature, it could be necessary to create a vast number of new dimensions resulting in a fact table with a very large number of foreign keys. The designer could also decide to leave the remaining attributes in the fact table but this could make the row length of the table unnecessarily large if, for example, the attribute is a long text string. The solution to this challenge is to identify all the attributes and then put them into one or several junk dimensions. One junk dimension can hold several true/false or yes/no indicators that have no correlation with each other, so it would be convenient to convert the indicators into a more describing attribute. An example would be an indicator about whether a package had arrived: instead of indicating this as “yes” or “no”, it would be converted into "arrived" or "pending" in the junk dimension. The designer can choose to build the dimension table so it ends up holding all the indicators occurring with every other indicator so that all combinations are covered. This sets up a fixed size for the table itself which would be 2x rows, where x is the number of indicators. This solution is appropriate in situations where the designer would expect to encounter a lot of different combinations and where the possible combinations are limited to an acceptable level. In a situation where the number of indicators are large, thus creating a very big table or where the designer only expects to encounter a few of the possible combinations, it would be more appropriate to build each row in the junk dimension as new combinations are encountered. To limit the size of the tables, multiple junk dimensions might be appropriate in other situations depending on the correlation between various indicators. Junk dimensions are also appropriate for placing attributes like non generic comments from the fact table. Such attributes might consist of data from an optional comment field when a customer places an order and as a result will probably be blank in many cases. Therefore, the junk dimension should contain a single row representing the blanks as a surrogate key that will be used in the fact table for every row returned with a blank comment field.
Өршілі өлшем
Бұзылған өлшем – атрибуттары жоқ, сондықтан нақты өлшем кестесімен байланыспайтын транзакция нөмірі, шот-фактура нөмірі, билет нөмірі немесе жүкқұжат нөмірі сияқты кілт. Бұзылған өлшемдер факт кестесінің гранулярлығы жеке транзакция элементін немесе жол элементін көрсететін кезде жиі кездеседі, себебі бұзылған өлшем ата-ананың бірегей идентификаторын ұсынады. Бұзылған өлшемдер көбінесе факт кестесінің біріншілік кілтінің құрамында маңызды рөл атқарады.
A degenerate dimension is a key, such as a transaction number, invoice number, ticket number, or bill of lading number, that has no attributes and hence does not join to an actual dimension table. Degenerate dimensions are very common when the grain of a fact table represents a single transaction item or line item because the degenerate dimension represents the unique identifier of the parent. Degenerate dimensions often play an integral role in the fact table's primary key.
Рөлдік ойын өлшемдері
Өлшемдер бір дерекқорында әртүрлі қолданыстар үшін жиі қайта қолданылады. Мысалы, "Күн" өлішемін "Сату күні", "Жеткізу күні" немесе "Жұмысқа қабылдану күні" үшін де пайдалануға болады. Мұндай өлішеме "рольдік өлішем" деп аталады. Бұл бір өлішем кестесі арқылы көрініс жасау арқылы іске асырылуы мүмкін.
Dimensions are often recycled for multiple applications within the same database. For instance, a "Date" dimension can be used for "Date of Sale", as well as "Date of Delivery", or "Date of Hire". This is often referred to as a "role playing dimension". This can be implemented using a view over the same dimension table.
Ауыспалы тұтқаның өлшемдері
Көбінесе өлшем кестелері сыртқы кілттер арқылы басқа өлшемдерге сілтеме жасамайды. Егер мұндай жағдай туындаса, сілтеме жасалған өлшемге «қосымша өлшем» (outrigger dimension) деп аталады. Қосымша өлшемдер деректер қоймасының дұрыс емес құрылымы саналады: екі өлшемді байланыстыратын фактілік кестелерді пайдалану артық көріледі.
Usually dimension tables do not reference other dimensions via foreign keys. When this happens, the referenced dimension is called an outrigger dimension. Outrigger dimensions should be considered a data warehouse anti pattern: it is considered a better practice to use some fact tables that relate the two dimensions.
Кішірейтілген өлшем
Қалыптасқан өлшем, егер ол бастапқы өлшемнің қатарларының және/немесе бағандарының бір бөлігін қамтитын болса, қысқартылған өлшем деп айтылады.
A conformed dimensions is said to be a shrunken dimension when it includes a subset of the rows and/or columns of the original dimension.
Күнтізбелік күн өлшемі
Күндік дәлдікпен күндерді көрсету үшін арнайы өлшем түрін пайдалануға болады. Күндер фактілер кестесінде күн өлшеміне сыртқы кілттер арқылы сілтеме жасалады. Күн өлшемінің біріншілік кілті YYYYMMDD форматындағы сан немесе жасалма кілт болуы мүмкін. Күн өлшемі жылдың аптасы сияқты басқа да атрибуттарды, сондай-ақ жұмыс күндерін, мерекелерді білдіретін белгілерді қамтуы мүмкін. Сондай-ақ, ол әлі белгілі емес немесе анықталмаған күндерді көрсететін арнайы қатарларды қамтуы мүмкін. Күн өлшемі барлық қажетті күндермен, мысалы, келесі 10 жылға немесе қажет болған жағдайда одан да көпке, ал өткен оқиғалар болса – өткен күндермен басталуы керек. Ал уақытты фактілер кестесінде уақыт белгісі ретінде көрсету әдетте тиімдірек.
A special type of dimension can be used to represent dates with a granularity of a day. Dates would be referenced in a fact table as foreign keys to a date dimension. The date dimension primary key could be a surrogate key or a number using the format YYYYMMDD. The date dimension can include other attributes like the week of the year, or flags representing work days, holidays, etc. It could also include special rows representing: not known dates, or yet to be defined dates. The date dimension should be initialized with all the required dates, say the next 10 years of dates, or more if required, or past dates if events in the past are handled. Time instead is usually best represented as a timestamp in the fact table.
ISO-ның бейнелеу терминдерін қолдану
ISO/IEC 11179 сияқты метадеректер тізілімінен деректерді сілтемелеген кезде "Индикатор" (нағыз/жалған бульдік мәні), "Код" (бірін бірі жаппай алмастырмайтын санамаланған мәндер жиынтығы) сияқты көрсетімдер өлшемдер ретінде қолданылады. Мысалы, Ұлттық ақпарат алмасу моделін (NIEM) пайдаланғанда дерек элементінің атауы "PersonGenderCode" болып келеді, ал санамаланған мәндер "ер", "әйел" және "белгісіз" болуы мүмкін.
When referencing data from a metadata registry such as ISO/IEC 11179, representation terms such as "Indicator" (a boolean true/false value), "Code" (a set of non overlapping enumerated values) are typically used as dimensions. For example, using the National Information Exchange Model (NIEM) the data element name would be "PersonGenderCode" and the enumerated values might be "male", "female" and "unknown".