Деректер базасы: Есептеулердегі ұйымдастырылған ақпарат жиынтығы

Кіріспе

Есептеудегі деректерді ұйымдастырылған жинағы – есептеу тұжырымдамасы.

Есептеуде деректер қоры – деректер базасын басқару жүйесінің (ДББС) пайдалануына негізделген деректердің ұйымдастырылған жинағы немесе деректерді сақтау түрі. ДББС – соңғы пайдаланушылармен, қосымшалармен және деректер қорының өзімен өзара әрекеттесетін бағдарламалық қамтамасыз ету, деректерді жинау және талдау үшін қолданылады. ДББС сонымен қатар деректер қорын басқаруға қажетті негізгі мүмкіндіктерді қамтиды. Деректер қорының, ДББС-тің және оған байланысты қосымшалардың жиынтығы деректер қоры жүйесі деп аталады. Көбінесе "деректер қоры" термині ДББС, деректер қоры жүйесі немесе деректер қорымен байланысты қосымшаны білдіру үшін кең мағынада қолданылады. Кіші деректер қорлары файлдық жүйеде сақталуы мүмкін, ал үлкен деректер қорлары компьютерлік кластерлерде немесе бұлтты сақтау орындарында орналастырылады. Деректер қорының дизайны формальды техникалар мен практикалық мәселелерді қамтиды, оның ішінде деректерді модельдеу, тиімді деректерді көрсету және сақтау, сұрату тілдері, құпиялы деректердің қауіпсіздігі мен құпиялылығы, сондай-ақ таратылған есептеу мәселелері, оның ішінде бір уақытта қол жеткізуді және қателерге төзімділікті қамтамасыз ету. Компьютер ғалымдары деректерді басқару жүйелерін олар қолдайтын деректер моделіне сәйкес жіктеуі мүмкін. 1980-ші жылдары реляциялық деректер қорлары басымдыққа ие болды. Олар деректерді кестелер тізбегіндегі қатарлар мен бағандар түрінде модельдейді және көпшілігі деректерді жазу және сұрау үшін SQL-ді пайдаланады. 2000-ші жылдары реляциялық емес деректер қорлары танымал болды, олар әртүрлі сұрату тілдерін қолданғандықтан NoSQL деп аталды.

Тарих

Деректер қорының және олардың тиісті ДБСҚ-ның (Деректерді басқару жүйесінің) мөлшері, мүмкіндіктері мен өнімділігі экспоненциалды түрде өсті. Бұл өнімділіктің артуы процессорлар, компьютерлік жад, компьютерлік сақтағыштар және компьютерлік желілер саласындағы технологиялық прогреске байланысты болды. Деректер қорының түсінігі магниттік дискілер сияқты тікелей қолжетімді сақтау орталарының пайда болуымен мүмкін болды, олар 1960 жылдардың ортасында кеңінен қолжетімді болды; алдыңғы жүйелер магниттік лентадағы деректерді тізбекті түрде сақтауға сүйенді. Деректер қоры технологиясының кейінгі дамуын деректер моделі немесе құрылымы бойынша үш кезеңге бөлуге болады: навигациялық, SQL/реляциялық және реляциялықтан кейінгі. Екі негізгі ерте навигациялық деректер моделі – иерархиялық модель және CODASYL моделі (желілік модель). Бұл модельдер бір жазбадан екіншісіне қатынастарды іздеу үшін көрсеткіштерді (көбінесе физикалық дискінің мекенжайларын) пайдаланумен сипатталды. 1970 жылы Эдгар Ф. Кодд ұсынған реляциялық модель бұл дәстүрден бас тартып, қолданбалар сілтемелерді орындаудың орнына деректерді мазмұны бойынша іздеуі керек деп талап етті. Реляциялық модель әрқайсысы әртүрлі нысандар үшін қолданылатын тізімдер сияқты кестелер жиынтығын қолданады. Компьютерлік аппараттық құралдар тек 1980 жылдардың ортасында ғана реляциялық жүйелерді (ДБСҚ және қолданбаларды) кеңінен енгізуге жеткілікті қуатты болды. Алайда, 1990 жылдардың басында реляциялық жүйелер барлық ірі масштабты деректерді өңдеу қолданбаларында басымдыққа ие болды және олар осы күйінде қалды: IBM Db2, Oracle, MySQL және Microsoft SQL Server ең көп ізделінетін ДБСҚ. Реляциялық модель үшін басым деректер қоры тілі, стандартталған SQL, басқа деректер модельдері үшін деректер қоры тілдеріне әсер етті. Объектілік деректер қоры 1980 жылдары нысан-реляциялық келеспессіздіктің ыңғайсыздығын жою үшін жасалды, бұл «реляциялықтан кейінгі» терминінің пайда болуына және гибридтік нысан-реляциялық деректер қорының дамуына әкелді. 2000 жылдардың соңында реляциялықтан кейінгі деректер қорының келесі буыны NoSQL деректер қоры ретінде танылды, ол жылдам кілт-мәнді сақтау орындарын және құжатқа бағытталған деректер қорын енгізді. «Келесі буын» деп аталатын бәсекелес NewSQL деректер қоры реляциялық/SQL моделін сақтай отырып, коммерциялық түрде қол жетімді реляциялық ДБСҚ-мен салыстырғанда NoSQL-дің жоғары өнімділігіне қол жеткізуге бағытталған жаңа іске асыруларды ұсынды.

The sizes, capabilities, and performance of databases and their respective DBMSs have grown in orders of magnitude. These performance increases were enabled by the technology progress in the areas of processors, computer memory, computer storage, and computer networks. The concept of a database was made possible by the emergence of direct access storage media such as magnetic disks, which became widely available in the mid 1960s; earlier systems relied on sequential storage of data on magnetic tape. The subsequent development of database technology can be divided into three eras based on data model or structure: navigational, SQL/relational, and post relational. The two main early navigational data models were the hierarchical model and the CODASYL model (network model). These were characterized by the use of pointers (often physical disk addresses) to follow relationships from one record to another. The relational model, first proposed in 1970 by Edgar F. Codd, departed from this tradition by insisting that applications should search for data by content, rather than by following links. The relational model employs sets of ledger style tables, each used for a different type of entity. Only in the mid 1980s did computing hardware become powerful enough to allow the wide deployment of relational systems (DBMSs plus applications). By the early 1990s, however, relational systems dominated in all large scale data processing applications, and they remain dominant: IBM Db2, Oracle, MySQL, and Microsoft SQL Server are the most searched DBMS. The dominant database language, standardized SQL for the relational model, has influenced database languages for other data models. Object databases were developed in the 1980s to overcome the inconvenience of object–relational impedance mismatch, which led to the coining of the term "post relational" and also the development of hybrid object–relational databases. The next generation of post relational databases in the late 2000s became known as NoSQL databases, introducing fast key–value stores and document oriented databases. A competing "next generation" known as NewSQL databases attempted new implementations that retained the relational/SQL model while aiming to match the high performance of NoSQL compared to commercially available relational DBMSs.

1970-ші жылдар, реляциялық ДҚББ

Эдгар Ф. Кодд Калифорния штатының Сан-Хосе қаласында IBM-де жұмыс істеді, олардың бір бөлімшесінде, ол негізінен қатты дискілер жүйесін әзірлеуге қатысты. Ол CODASYL тәсілінің навигациялық моделіне, әсіресе "іздестіру" мүмкіндігінің болмауына наразы еді. 1970 жылы ол деректер базасын құрудың жаңа тәсілін сипаттайтын бірқатар мақалалар жазды, олар ақырында "Үлкен ортақ деректер қоймалары үшін реляциялық модель" деген маңызды жаңалыққа әкелді. Бұл мақалада ол үлкен деректер базасын сақтау және онымен жұмыс істеудің жаңа жүйесін сипаттады. CODASYL-дегідей, еркін пішіндегі жазбалардың тізбегіне сақталатын жазбалардың орнына, Коддтың идеясы деректерді бірнеше "кестелер" ретінде ұйымдастыру болды, әр кесте әртүрлі нысан үшін пайдаланылады. Әрбір кестеде нысанның атрибуттарын қамтитын белгілі бір саны бағандар болады. Әрбір кестедегі бір немесе бірнеше бағандар негізгі кілт ретінде белгіленеді, олар арқылы кестедегі қатарларды бірегей анықтауға болады; кестелер арасындағы сілтемелер әрқашан осы негізгі кілттерді, дискілік мекенжайларды емес, пайдаланады, ал сұраныстар осы кілттік қатынастарға негізделген кестелерді қосады, реляциялық есептеудің математикалық жүйесіне негізделген операциялар жиынтығын қолдана отырып (модель осы жүйеден атын алған). Деректерді нормаланған кестелерге (немесе қатынастарға) бөлу, әрбір "фактінің" бір рет сақталуын қамтамасыз етуді мақсат етеді, осылайша жаңарту операцияларын жеңілдетуге болады. Көріністер деп аталатын виртуалды кестелер әртүрлі пайдаланушылар үшін деректерді әртүрлі форматта көрсетуге мүмкіндік береді, бірақ көріністерді тікелей жаңартуға болмайды. Кодд модельді анықтау үшін математикалық терминдерді қолданды: кестелер, қатарлар және бағандар емес, қатынастар, топтамалар және домендер. Қазіргі таныс терминология алғашқы іске асырулардан келді. Кейін Кодд практикалық іске асырудың модельдің математикалық негіздерінен ауытқуға бейімділігін сынады. Кестелер арасындағы қатынастарды көрсету үшін дискілік мекенжайлардың орнына негізгі кілттерді (пайдаланушыға бағытталған идентификаторларды) қолданудың екі негізгі себебі болды. Инженерлік тұрғысынан алғанда, бұл кестелерді қымбат деректер қорын қайта ұйымдастырусыз жылжытуға және өлшемдерін өзгертуге мүмкіндік берді. Бірақ Коддты семантикадағы айырмашылық көбірек қызықтырды: нақты идентификаторларды қолдану жаңарту операцияларын анық математикалық анықтамалармен анықтауға мүмкіндік берді, сонымен қатар сұраныс операцияларын бірінші реттік предикаттық есептеудің қалыптасқан саласының тұрғысынан анықтауға мүмкіндік берді; өйткені бұл операциялардың анық математикалық қасиеттері бар, сұраныстарды дәлелдеуге болатын дұрыс жолдармен қайта жазуға болады, бұл сұраныс оптимизациясының негізі болып табылады. Иерархиялық немесе желілік модельдермен салыстырғанда экспрессивтілік жоғалмайды, бірақ кестелер арасындағы байланыстар енді соншалықты анық емес. Иерархиялық және желілік модельдерде жазбалардың күрделі ішкі құрылымы болуы мүмкін. Мысалы, қызметкердің жалақы тарихы қызметкер жазбасында "қайталанатын топ" ретінде көрсетілуі мүмкін. Реляциялық модельде нормалдау процесі мұндай ішкі құрылымдарды бірнеше кестеде сақталатын деректермен, олар тек логикалық кілттермен байланыстырылған, алмастыруға әкелді. Мысалы, деректер базасы жүйесін пайдаланушылар туралы ақпаратты, олардың атын, кіру деректерін, әртүрлі мекенжайларын және телефон нөмірлерін бақылау үшін жиі қолданылады. Навигациялық тәсілде барлық осы деректер бір өзгермелі ұзындығы бар жазбаға орналастырылады. Реляциялық тәсілде деректер пайдаланушы кестесіне, мекенжай кестесіне және телефон нөмірі кестесіне (мысалы) нормалданады. Бұл қосымша кестелерде жазбалар тек мекенжай немесе телефон нөмірлері берілген жағдайда ғана құрылады. Дискілік мекенжайлардың орнына логикалық идентификаторларды қолдана отырып, қатарларды/жазбаларды анықтаумен қатар, Кодд бірнеше жазбалардан деректерді жинақтау әдісін өзгертті. Қолданбалардан бір уақытта бір жазбаны сілтемелерді аралап, деректерді жинауды талап етудің орнына, олар қандай деректерді іздеу керектігін көрсететін декларативтік сұраныс тілін қолданады, бірақ оны табу керек жолды емес. Деректерге тиімді кіру жолын табу қолданбалы бағдарламалаушының емес, деректер базасын басқару жүйесінің жауапкершілігіне айналды. Бұл процесс, сұраныс оптимизациясы деп аталады, сұраныстар математикалық логиканың терминдерімен берілгеніне байланысты. Коддтың мақаласын Берклидегі екі адам, Эжен Вонг және Майкл Стоунбрейкер қолға алды. Олар географиялық деректер базасы жобасы үшін бұрын бөлінген қаражатты және студент бағдарламашыларды қолданып, INGRES деп аталатын жобаны бастады. 1973 жылдан бастап, INGRES өзінің алғашқы сынақ өнімдерін ұсынды, олар 1979 жылы кеңінен қолдануға дайын болды. INGRES көптеген жағынан System R-ға ұқсас болды, соның ішінде деректерге кіру үшін "тіл" пайдаланылды, ол QUEL деп белгіленді. Уақыт өте келе, INGRES жаңа SQL стандартына көшті. IBM өзі реляциялық модельдің бір сынақ және бір өндірістік іске асыруын жасады, PRTV және Business System 12, екеуі де қазір тоқтатылды. Honeywell Multics үшін MRDS жазды, ал қазір екі жаңа іске асыру бар: Alphora Dataphor және Rel. Басқа көптеген ДБС іске асырулары, әдетте реляциялық деп аталады, шындығында SQL ДБС-тері болып табылады. 1970 жылы Мичиган университеті D. L. Childs-тың жиындық теориялық деректер моделіне негізделген MICRO ақпаратты басқару жүйесін әзірлеуді бастады. MICRO АҚШ Еңбек департаменті, АҚШ Қоршаған ортаны қорғау агенттігі және Альберта университеті, Мичиган университеті және Уэйн мемлекеттік университетінің зерттеушілерімен үлкен деректер жиындықтарын басқару үшін пайдаланылды. Ол Мичиган терминалдық жүйесін пайдалана отырып, IBM негізгі компьютерлерінде жұмыс істеді. Жүйе 1998 жылға дейін өндірісте болды.

Edgar F. Codd worked at IBM in San Jose, California, in one of their offshoot offices that were primarily involved in the development of hard disk systems. He was unhappy with the navigational model of the CODASYL approach, notably the lack of a "search" facility. In 1970, he wrote a number of papers that outlined a new approach to database construction that eventually culminated in the groundbreaking A Relational Model of Data for Large Shared Data Banks. In this paper, he described a new system for storing and working with large databases. Instead of records being stored in some sort of linked list of free form records as in CODASYL, Codd's idea was to organize the data as a number of "tables", each table being used for a different type of entity. Each table would contain a fixed number of columns containing the attributes of the entity. One or more columns of each table were designated as a primary key by which the rows of the table could be uniquely identified; cross references between tables always used these primary keys, rather than disk addresses, and queries would join tables based on these key relationships, using a set of operations based on the mathematical system of relational calculus (from which the model takes its name). Splitting the data into a set of normalized tables (or relations) aimed to ensure that each "fact" was only stored once, thus simplifying update operations. Virtual tables called views could present the data in different ways for different users, but views could not be directly updated. Codd used mathematical terms to define the model: relations, tuples, and domains rather than tables, rows, and columns. The terminology that is now familiar came from early implementations. Codd would later criticize the tendency for practical implementations to depart from the mathematical foundations on which the model was based. The use of primary keys (user oriented identifiers) to represent cross table relationships, rather than disk addresses, had two primary motivations. From an engineering perspective, it enabled tables to be relocated and resized without expensive database reorganization. But Codd was more interested in the difference in semantics: the use of explicit identifiers made it easier to define update operations with clean mathematical definitions, and it also enabled query operations to be defined in terms of the established discipline of first order predicate calculus; because these operations have clean mathematical properties, it becomes possible to rewrite queries in provably correct ways, which is the basis of query optimization. There is no loss of expressiveness compared with the hierarchic or network models, though the connections between tables are no longer so explicit. In the hierarchic and network models, records were allowed to have a complex internal structure. For example, the salary history of an employee might be represented as a "repeating group" within the employee record. In the relational model, the process of normalization led to such internal structures being replaced by data held in multiple tables, connected only by logical keys. For instance, a common use of a database system is to track information about users, their name, login information, various addresses and phone numbers. In the navigational approach, all of this data would be placed in a single variable length record. In the relational approach, the data would be normalized into a user table, an address table and a phone number table (for instance). Records would be created in these optional tables only if the address or phone numbers were actually provided. As well as identifying rows/records using logical identifiers rather than disk addresses, Codd changed the way in which applications assembled data from multiple records. Rather than requiring applications to gather data one record at a time by navigating the links, they would use a declarative query language that expressed what data was required, rather than the access path by which it should be found. Finding an efficient access path to the data became the responsibility of the database management system, rather than the application programmer. This process, called query optimization, depended on the fact that queries were expressed in terms of mathematical logic. Codd's paper was picked up by two people at Berkeley, Eugene Wong and Michael Stonebraker. They started a project known as INGRES using funding that had already been allocated for a geographical database project and student programmers to produce code. Beginning in 1973, INGRES delivered its first test products which were generally ready for widespread use in 1979. INGRES was similar to System R in a number of ways, including the use of a "language" for data access, known as QUEL. Over time, INGRES moved to the emerging SQL standard. IBM itself did one test implementation of the relational model, PRTV, and a production one, Business System 12, both now discontinued. Honeywell wrote MRDS for Multics, and now there are two new implementations: Alphora Dataphor and Rel. Most other DBMS implementations usually called relational are actually SQL DBMSs. In 1970, the University of Michigan began development of the MICRO Information Management System based on D. L. Childs' Set Theoretic Data model. MICRO was used to manage very large data sets by the US Department of Labor, the U. S. Environmental Protection Agency, and researchers from the University of Alberta, the University of Michigan, and Wayne State University. It ran on IBM mainframe computers using the Michigan Terminal System. The system remained in production until 1998.

Интегралды тәсіл

1970 және 1980 жылдары интеграцияланған аппараттық және бағдарламалық құралдармен деректер базасы жүйелерін құруға әрекеттер жасалды. Бұл тәсілдің негізгі идеясы – мұндай интеграция арқылы төмен құнмен жоғары өнімділікке қол жеткізу. Мысалдарға IBM System/38, Teradata-ның бастапқы өнімдері және Britton Lee, Inc. деректер базасы машинасы жатады. Деректерді басқаруға аппараттық қолдау көрсетудің тағы бір жолы – ICL CAFS үдеткіші, ол бағдарламаланатын іздеу мүмкіндіктері бар аппараттық дискі контроллері болды. Ұзақ мерзімді перспективада бұл күш-жігер көбінесе сәтсіз аяқталды, себебі арнайы деректер базасы машиналары жалпы мақсаттағы компьютерлердің қарқынды дамуымен және прогресімен қадамдаса алмады. Сондықтан қазіргі деректер базасы жүйелерінің көпшілігі жалпы мақсаттағы аппараттық құралдарда жұмыс істейтін бағдарламалық жүйелер болып табылады, олар жалпы мақсаттағы компьютерлік деректерді сақтауды пайдаланады. Дегенмен, бұл идея Netezza және Oracle (Exadata) сияқты кейбір компаниялар тарапынан белгілі бір қолданбаларда әлі де қолданылуда.

1970-ші жылдардың аяғы, SQL DBMS

IBM 1970-ші жылдардың басында Коддтың тұжырымдамаларына негізделген прототиптік жүйеде System R ретінде жұмыс істей бастады. Бірінші нұсқа 1974/75 жылдары дайын болды, содан кейін деректер бір жазба үшін барлық деректерді (кейбіреуі міндетті емес) бір үлкен "блокта" сақтаудың қажеті жоқ, сондықтан деректер бөлінетін көптеген кестелік жүйелер бойынша жұмыс басталды. Кейінгі көп пайдаланушы нұсқалары 1978 және 1979 жылдары клиенттермен сыналып көрiлдi, сол кезде стандартталған сұраныс тілі – SQL – қосылды. Коддтың идеялары CODASYL-ге қарағанда тиімді және жоғары екенін көрсетті, бұл IBM-ді SQL/DS деп аталатын System R-дің толыққанды өндірістік нұсқасын және кейіннен Database 2 (IBM Db2) әзірлеуге итермеледі. Ларри Эллисонның Oracle деректер қоры (немесе, қысқасы, Oracle) IBM-нің System R туралы жарияланымдарына негізделген басқа бағытта дамыды. Oracle V1 нұсқаларының жұмысы 1978 жылы аяқталса да, Эллисон 1979 жылы Oracle Version 2 нұсқасын нарыққа шығарғанға дейін IBM-ді озып кетпеді. Stonebraker INGRES-тен алған тәжірибесін пайдаланып, Postgres деп аталатын жаңа деректер қорын жасады, ол қазір PostgreSQL деп белгілі. PostgreSQL көбінесе жаһандық маңызды міндеттерді атқаратын қосымшалар үшін қолданылады (ұйымдар мен ақпараттық домендік атаулар тізілімдері оны негізгі деректер қоймасы ретінде пайдаланады, сондай-ақ көптеген ірі компаниялар мен қаржы институттары да қолданады). Швецияда Коддтың мақаласы оқылды және 1970-ші жылдардың ортасында Уппсала университетінде Mimer SQL әзірленді. 1984 жылы бұл жоба тәуелсіз кәсіпорынға біріктірілді. Тағы бір дерек моделі – entity-relationship моделі 1976 жылы пайда болды және деректер базасын жобалауда танымал болды, себебі ол бұрынғы реляциялық модельге қарағанда түсініктірек сипаттамаға баса назар аударды. Кейіннен, entity-relationship құрылымдары реляциялық модель үшін деректерді модельдеу құралы ретінде қайта жаңартылды және екеуінің арасындағы айырмашылық маңызсыз болды.

1980 жылдар, үстел үстінде

1980 жылдары үстел компьютерлерінің дәуірі басталды. Жаңа компьютерлер пайдаланушыларға Lotus 1 2 3 сияқты электрондық кестелер мен dBASE сияқты деректер базасы бағдарламалық қамтамасыздарын ұсынды. dBASE өнімі жеңіл салмақты және кез келген компьютер пайдаланушысына бірден түсінікті болды. dBASE бағдарламасын жасаған К. Уэйн Ратлифф: «dBASE, BASIC, C, FORTRAN және COBOL сияқты бағдарламалардан соңғы жұмыстардың көп бөлігі бұрыннан жасалғандықтан ерекшеленеді. Деректерді өңдеуді пайдаланушы емес, dBASE жүзеге асырады, сондықтан пайдаланушы файлдарды ашу, оқу және жабу, жадты бөлу сияқты күрделі мәселелермен айналыспай, не істеп жатқанына назар аудара алады» деді. dBASE 1980 және 1990 жылдардың басында ең көп сатылған бағдарламалық қамтамасыздардың бірі болды.

1990 жылдар, объектке бағдарланған

1990 жылдары объектіге бағытталған бағдарламалаудың дамуымен қатар, әртүрлі деректер базаларындағы деректерді өңдеу тәсілдері де өсті. Бағдарламашылар мен дизайнерлер өз деректер базаларындағы деректерді объектілер ретінде қарастыра бастады. Яғни, егер адам туралы деректер деректер базасында сақталса, онда оның мекенжайы, телефон нөмірі және жасы сияқты атрибуттары енді осы адамға тиесілі болып саналады, ал бұрын олар бөлек деректер ретінде қарастырылатын. Бұл деректер арасындағы байланыстарды жекелеген өрістерге емес, объектілер мен олардың атрибуттарына қатыстыруға мүмкіндік береді. "Объекті-реляциялық үйлесімсіздік" термині бағдарламаланған объектілер мен деректер базасы кестелері арасындағы аударманың қиындығын сипаттайды. Объектілік деректер базалары және объекті-реляциялық деректер базалары осы мәселені объектіге бағытталған тілді (кейде SQL-ге қосымша ретінде) ұсыну арқылы шешуге тырысады, оны бағдарламашылар таза реляциялық SQL-ге балама ретінде қолдана алады. Бағдарламалау тарапынан, объекті-реляциялық бейнелеу (ORM) деп аталатын кітапханалар осы мәселені шешуге көмектеседі.

2000-шы жылдар, NoSQL және NewSQL

XML деректер қоры – XML құжатының атрибуттарына негізделген сұрау салуға мүмкіндік беретін құрылымдық құжатқа бағытталған деректер қорының түрі. XML деректер қоры көбінесе деректерді құжаттар жинағы ретінде қарастыру ыңғайлы болған және құрылымы өте икемдіден қатаңға дейін өзгеріп отыруы мүмкін қолданбаларда қолданылады: мысалдарға ғылыми мақалалар, патенттер, салық есептемелері және жеке құрамдық мәліметтер жатады. NoSQL деректер қоры көбінесе өте жылдам, белгілі бір кесте схемаларын қажет етпейді, денормализацияланған деректерді сақтау арқылы қосылу операцияларынан аулақ салады және көлденең масштабтауға арналған. Соңғы жылдары жоғары бөлінуге төзімділікпен, кеңінен таралған деректер қорына сұраныс артып, бірақ CAP теоремасына сәйкес, таратылған жүйе бір уақытта тұрақтылық, қолжетімділік және бөлінуге төзімділік кепілдіктерін қамтамасыз ете алмайды. Таратылған жүйе осы кепілдіктердің кез келген екеуін бір уақытта орындай алады, бірақ барлығын емес. Осы себепті көптеген NoSQL деректер қоры деректердің тұрақтылығын төмендету арқылы қолжетімділік пен бөлінуге төзімділік кепілдіктерін қамтамасыз ету үшін «соңғы сәйкестік» деп аталатын әдіс қолданады. NewSQL – бұл SQL-ді қолдана отырып және дәстүрлі деректер қоры жүйесінің ACID кепілдіктерін сақтай отырып, онлайн транзакцияларды өңдеу (оқу-жазу) жүктемелері үшін NoSQL жүйелерінің сол деңгейдегі өнімділігін қамтамасыз етуді мақсат ететін қазіргі заманғы реляциялық деректер қорының класы.

Пайдалану жағдайлары

Деректер базасы ұйымдардың ішкі жұмысын қолдауға, сондай-ақ клиенттермен және жеткізушілермен онлайн әрекеттесуді қамтамасыз етуге пайдаланылады (Кәсіпорындық бағдарламалық құралдарды қараңыз). Деректер базасы әкімшілік ақпаратты, сонымен қатар инженерлік деректер немесе экономикалық модельдер сияқты арнайы деректерді сақтау үшін қолданылады. Мысалдарға компьютерлендірілген кітапхана жүйелері, авиабилеттерді брондау жүйелері, компьютерлендірілген запбөлшектер тізімі жүйелері және веб-сайттарды веб-беттер жиынтығы ретінде деректер базасында сақтайтын көптеген контентті басқару жүйелері жатады.

Қолдану

Деректер базасымен сыртқы өзара әрекеттесу деректерді басқару жүйесімен (ҚБЖБ) байланыс жасайтын қолданба бағдарламасы арқылы жүзеге асырылады. Бұл, пайдаланушыларға SQL сұраныстарын мәтіндік немесе графикалық түрде орындауға мүмкіндік беретін деректер базасы құралынан бастап, ақпаратты сақтау және іздеу үшін деректер базасын пайдаланатын веб-сайтқа дейін болуы мүмкін.

Қолданбалық бағдарлама интерфейсі

Бағдарламашы деректер базасымен (кейде деректер көзі деп аталады) өзара әрекеттесуді қолданбалық бағдарлама интерфейсі (API) немесе деректер базасы тілі арқылы бағдарламалайды. Таңдалған нақты API немесе тілді ДБЖС (Деректерді басқару жүйесі), мүмкін, алдын ала өңдеуші немесе байланыстырушы API арқылы қолдауы керек. Кейбір API-лер деректер базасынан тәуелсіз болуға тырысады, ODBC оның кең таралған мысалы. Басқа дамыған API-лерге JDBC және ADO.NET кіреді.

Сақтау

Деректер қорын сақтау – деректер қорының физикалық түрінің контейнері. Ол деректер базасы архитектурасындағы ішкі (физикалық) деңгейді құрайды. Сондай-ақ, қажет болған жағдайда ішкі деңгейден тұжырымдық және сыртқы деңгейді қайта құру үшін қажетті барлық ақпаратты (мысалы, метадеректер, «деректер туралы деректер» және ішкі деректер құрылымдары) қамтиды. Деректер қоры цифрлық нысан ретінде үш түрлі ақпаратты қамтиды: деректер, құрылым және семантика. Деректер қорының болашақта сақталуы мен ұзақ мерзімді қолданылуы үшін осы үш қабатты дұрыс сақтау қажет. Деректерді тұрақты сақтау әдетте деректер базасының қозғалтқышының, басқаша айтқанда «сақтау қозғалтқышының» жауапкершілігінде болады. DBMS әдетте негізгі операциялық жүйе арқылы қол жеткізеді (көбінесе операциялық жүйелердің файлдық жүйелері сақтау құрылымын ұйымдастыру үшін аралық құрал ретінде қолданылады), бірақ сақтау қасиеттері мен конфигурация параметрлері DBMS-тің тиімді жұмыс істеуі үшін маңызды, сондықтан деректер базасының әкімшілері оларды қатаң бақылайды. Жұмыс істеп тұрған кезде DBMS әрқашан бірнеше сақтау түрінде орналасқан деректер қорына ие болады (мысалы, жад және сыртқы сақтау). Деректер қорының деректері мен қосымша қажетті ақпарат, көбінесе үлкен көлемде, биттерге түрлендіріледі. Деректер әдетте тұжырымдық және сыртқы деңгейлерде көрінетін түрінен мүлдем өзгеше құрылымдарда сақталады, бірақ пайдаланушылар мен бағдарламаларға қажет болған кезде осы деңгейлерді қалпына келтіруді (мүмкіндігінше жақсы) оңтайландыруға, сондай-ақ деректерден қосымша ақпаратты есептеуге (мысалы, деректер қорына сұрақтар жіберген кезде) бағытталған тәсілдермен сақталады. Кейбір DBMS деректерді сақтау үшін қолданылған таңба кодтамасын көрсетуге мүмкіндік береді, сондықтан бір деректер қорында бірнеше кодтама қолданылуы мүмкін. Сақтау қозғалтқышы деректер моделін сериалдау үшін әртүрлі төменгі деңгейдегі деректер базасын сақтау құрылымдарын пайдаланады, осылайша оны таңдалған ортаға жазуға болады. Орындалу жылдамдығын арттыру үшін индекстеу сияқты техникалар қолданылуы мүмкін. Көбінесе сақтау қатарға бағдарланған болады, бірақ бағанға бағдарланған және корреляциялық деректер қоры да бар.

Database storage is the container of the physical materialization of a database. It comprises the internal (physical) level in the database architecture. It also contains all the information needed (e. g., metadata, "data about the data", and internal data structures) to reconstruct the conceptual level and external level from the internal level when needed. Databases as digital objects contain three layers of information which must be stored: the data, the structure, and the semantics. Proper storage of all three layers is needed for future preservation and longevity of the database. Putting data into permanent storage is generally the responsibility of the database engine a. k. a. "storage engine". Though typically accessed by a DBMS through the underlying operating system (and often using the operating systems' file systems as intermediates for storage layout), storage properties and configuration settings are extremely important for the efficient operation of the DBMS, and thus are closely maintained by database administrators. A DBMS, while in operation, always has its database residing in several types of storage (e. g., memory and external storage). The database data and the additional needed information, possibly in very large amounts, are coded into bits. Data typically reside in the storage in structures that look completely different from the way the data look at the conceptual and external levels, but in ways that attempt to optimize (the best possible) these levels' reconstruction when needed by users and programs, as well as for computing additional types of needed information from the data (e. g., when querying the database). Some DBMSs support specifying which character encoding was used to store data, so multiple encodings can be used in the same database. Various low level database storage structures are used by the storage engine to serialize the data model so it can be written to the medium of choice. Techniques such as indexing may be used to improve performance. Conventional storage is row oriented, but there are also column oriented and correlation databases.

Материалдық көзқарастар

Көп жағдайда өнімділікті арттыру үшін сақтаудың қосымша көшірмесі пайдаланылады. Көрінетін мысал – жиі қолданылатын сыртқы көріністерді немесе сұрау нәтижелерін қамтитын материалдық көріністерді сақтау. Мұндай көріністерді сақтау, оларды әр қолданылған сайын қайта есептеуге кететін қымбатты еңбекті үнемдейді. Материалдық көріністердің кемшіліктері – бастапқы деректер базасы жаңарып жатқанда оларды синхронды ұстау үшін жаңарту кезінде туындайтын қосымша шығындар және сақтаудың қосымша көшірмесіне кететін шығын.

Көшіру

Кейде деректер қоры деректер базасы объектілерін көшіру арқылы (бір немесе бірнеше данасы бар) сақтаудың артықшылығын пайдаланады. Бұл деректерге қолжетімділікті арттыру үшін жасалады (бір деректер базасының объектісіне бір мезгілде көптеген пайдаланушының кіру жылдамдығын арттыру және таратылған деректер базасының ішінара бұзылу жағдайында сенімділікті қамтамасыз ету үшін). Көшірілген объектіні жаңарту деректердің барлық даналарымен синхрондалуы керек. Көп жағдайда, бүкіл деректер қоры көшіріледі.

Виртуализациялау

Деректерді виртуализациялау арқылы қолданылатын деректер бастапқы орналасқан жерінде қалады және әртүрлі көздерден талдау жасауға мүмкіндік беретін дереу қол жеткізу құрылады. Бұл әртүрлі платформалардан деректерді біріктіру кезінде туындайтын үйлесімділік мәселелерін шешуге, бұрмаланған деректерден болатын қателерді азайтуға және ең жаңа деректердің қолданылуын қамтамасыз етуге көмектеседі. Сонымен қатар, жеке ақпаратты қамтитын жаңа деректер базасын жасаудан аулақ болу құпиялылық талаптарын орындауды жеңілдетеді. Алайда, деректерді виртуализациялау кезінде деректердің жергілікті көшірмесі болмайтындықтан, барлық қажетті дерек көздеріне қосылыс үздіксіз жұмыс істеуі тиіс, бұл осы тәсілдің басты кемшіліктерінің бірі.

Қауіпсіздік

Деректер қорының қауіпсіздігі – деректер қорының мазмұнын, оның иелерін және пайдаланушыларын қорғаудың барлық түрлі аспектілерін қамтиды. Ол деректер қорын қасақана түрде рұқсатсыз пайдаланудан бастап, рұқсатсыз тұлғалардың (мысалы, адам немесе компьютерлік бағдарлама) кездейсоқ деректерге қол жеткізуіне дейін қорғауды қамтиды. Деректер қорына қол жеткізуді басқару – деректер қорындағы қандай ақпаратқа кімге (адамға немесе белгілі бір компьютерлік бағдарламаға) рұқсат берілетінін бақылауды қамтиды. Ақпаратқа нақты деректер қоры объектілері (мысалы, жазба түрлері, нақты жазбалар, деректер құрылымдары), белгілі бір объектілер бойынша есептеулер (мысалы, сұраныс түрлері немесе нақты сұраныстар) немесе оларға қол жеткізудің арнайы жолдары (мысалы, ақпаратты алу үшін арнайы индекстер немесе басқа деректер құрылымдарын пайдалану) кіруі мүмкін. Деректер қорына қол жеткізуді басқару деректер қорының иесімен уәкілеттік берілген арнайы персонал жүзеге асырады, олар арнайы қорғалған қауіпсіздік DBMS интерфейстерін пайдаланады. Бұл тікелей жеке негізде, немесе жеке тұлғаларға және топтарға артықшылықтарды беру арқылы, немесе (ең күрделі модельдерде) жеке тұлғалар мен топтарды рөлдерге тағайындау арқылы, содан кейін оларға құқықтар беру арқылы басқарылуы мүмкін. Деректер қауіпсіздігі рұқсатсыз пайдаланушылардың деректер қорын қарауын немесе жаңартуын болдырмайды. Парольдерді пайдалану арқылы пайдаланушыларға бүкіл деректер қорына немесе оның "қосалқы схемалары" деп аталатын бөліктеріне қол жеткізуге рұқсат беріледі. Мысалы, қызметкер туралы деректер қорында жеке қызметкер туралы барлық ақпарат болуы мүмкін, бірақ бір топ пайдаланушыларға тек еңбекақы туралы деректерді көруге рұқсат етілсе, ал басқаларына тек жұмыс тарихы мен медициналық деректерге қол жеткізуге рұқсат беріледі. Егер DBMS деректер қорына интерактивті түрде кіру, жаңарту және сұрау мүмкіндігін қамтамасыз етсе, бұл мүмкіндік жеке деректер қорын басқаруға мүмкіндік береді. Деректер қауіпсіздігі, әдетте, деректердің нақты бөліктерін физикалық тұрғыдан (яғни, зақымданудан, жойылудан немесе жоюдан; мысалы, физикалық қауіпсіздікке қараңыз) немесе оларды мағыналы ақпаратқа түсіндіруден қорғаумен айналысады (мысалы, оларды құрайтын биттер тізбесін қарап, жарамды кредиттік карта нөмірін анықтау арқылы; мысалы, деректерді шифрлауды қараңыз). Өзгерістер мен қол жеткізу журналы қай атрибуттарға кіргенін, не өзгергенін және қашан өзгергенін тіркеп сақтайды. Журналдау қызметтері кіру оқиғалары мен өзгерістердің тіркелмесін сақтау арқылы кейінірек деректер қорының сот-медициналық аудитін жүргізуге мүмкіндік береді. Кейде қолданба деңгейіндегі код өзгерістерді тіркеу үшін қолданылады, оларды деректер базасында қалдырудың орнына. Қауіпсіздік бұзушылықтарын анықтау үшін бақылау орнатылуы мүмкін. Сондықтан ұйымдар деректер қорының қауіпсіздігін қастерлеуі керек, себебі ол көптеген пайдалар береді. Ұйымдар қауіпсіздік бұзушылықтарынан және хакерлік әрекеттерден, мысалы, өрт қабырғасын бұзудан, вирустардың таралуынан және қорғау құралдарынан қорғалады. Бұл компанияның маңызды ақпаратын қорғауға көмектеседі, оны ешбір жағдайда сырттан кімдермен бөлісуге болмайды.

Database security deals with all various aspects of protecting the database content, its owners, and its users. It ranges from protection from intentional unauthorized database uses to unintentional database accesses by unauthorized entities (e. g., a person or a computer program). Database access control deals with controlling who (a person or a certain computer program) are allowed to access what information in the database. The information may comprise specific database objects (e. g., record types, specific records, data structures), certain computations over certain objects (e. g., query types, or specific queries), or using specific access paths to the former (e. g., using specific indexes or other data structures to access information). Database access controls are set by special authorized (by the database owner) personnel that uses dedicated protected security DBMS interfaces. This may be managed directly on an individual basis, or by the assignment of individuals and privileges to groups, or (in the most elaborate models) through the assignment of individuals and groups to roles which are then granted entitlements. Data security prevents unauthorized users from viewing or updating the database. Using passwords, users are allowed access to the entire database or subsets of it called "subschemas". For example, an employee database can contain all the data about an individual employee, but one group of users may be authorized to view only payroll data, while others are allowed access to only work history and medical data. If the DBMS provides a way to interactively enter and update the database, as well as interrogate it, this capability allows for managing personal databases. Data security in general deals with protecting specific chunks of data, both physically (i. e., from corruption, or destruction, or removal; e. g., see physical security), or the interpretation of them, or parts of them to meaningful information (e. g., by looking at the strings of bits that they comprise, concluding specific valid credit card numbers; e. g., see data encryption). Change and access logging records who accessed which attributes, what was changed, and when it was changed. Logging services allow for a forensic database audit later by keeping a record of access occurrences and changes. Sometimes application level code is used to record changes rather than leaving this in the database. Monitoring can be set up to attempt to detect security breaches. Therefore, organizations must take database security seriously because of the many benefits it provides. Organizations will be safeguarded from security breaches and hacking activities like firewall intrusion, virus spread, and ransom ware. This helps in protecting the company's essential information, which cannot be shared with outsiders at any cause.

Өнімдер мен бір мезгілде жасалатын операциялар

Деректер қорының транзакциялары апаттан кейін қалпына келтіру кезінде белгілі бір деңгейде қатеге төзімділік пен деректердің тұтастығын қамтамасыз ету үшін қолданылуы мүмкін. Деректер қорының транзакциясы – жұмыстың бірлігі, әдетте деректер қорында бірнеше операцияны қамтиды (мысалы, деректер қорының нысанын оқу, жазу, құлыпты алу немесе босату сияқты). Бұл деректер қорында және басқа да жүйелерде қолдау көрсетілетін абстракция. Әрбір транзакция нақты шекаралармен анықталады, олар бойынша бағдарламаның/кодтың қандай орындалулары осы транзакцияға кіретіні белгіленеді (бұл транзакцияның бағдарламашысы арнайы транзакция командалары арқылы анықталады). ACID аббревиатурасы деректер қоры транзакциясының идеалды қасиеттерін сипаттайды: атомдық, үйлесімділік, оқшаулану және беріктік.

Көші-қон

Бір ДҚБЖ-мен құрылған деректер қоры басқа ДҚБЖ-ға көшіріле алмайды (яғни, екінші ДҚБЖ оны іске қоса алмайды). Дегенмен, кейбір жағдайларда деректер қорын бір ДҚБЖ-дан екіншісіне міграциялау қажет болуы мүмкін. Мұның басты себептері экономикалық (әр түрлі ДҚБЖ-дың жалпы меншік құны немесе ТКЖ әртүрлі болуы мүмкін), функционалдық және операциялық (әр түрлі ДҚБЖ-дың мүмкіндіктері әртүрлі болуы мүмкін) сипатта болады. Міграция – деректер қорының бір ДҚБЖ түрінен екіншісіне түрлендірілуі. Түрлендіру кезінде (мүмкін болса) деректер қорымен байланысты қолданба (яғни, барлық байланысты қолданба бағдарламалары) өзгеріссіз сақталуы тиіс. Осылайша, деректер қорының түсініктелмелі және сыртқы архитектуралық деңгейлері түрлендіруде сақталуы керек. Архитектураның ішкі деңгейдегі кейбір аспектілері де сақталуы ықтимал. Күрделі немесе үлкен деректер қорын міграциялау – бұл өзіндік дербес және қымбат (бір реттік) жоба болуы мүмкін, сондықтан міграциялау туралы шешім қабылдағанда оны ескеру қажет. Бұл, нақты ДҚБЖ арасында міграцияға көмектесетін құралдардың болуына қарамастан. Әдетте, ДҚБЖ жеткізуші басқа танымал ДҚБЖ-дан деректер қорын импорттауға көмектесетін құралдарды ұсынады.

Құрылыс, техникалық қызмет көрсету және баптау

Қолданба үшін деректер қорын жобалағаннан кейін келесі кезең – деректер қорын құру. Әдетте, осы мақсатта қолданылатын мақсатына сәйкес келетін ДҚБЖ-ны таңдауға болады. ДҚБЖ деректер базасының әкімшілеріне қажетті деректер құрылымдарын ДҚБЖ-ның тиісті деректер моделінде анықтау үшін қажетті пайдаланушы интерфейстерін ұсынады. Қажетті ДҚБЖ параметрлерін (мысалы, қауіпсіздікке қатысты, жадты бөлу параметрлері және т.б.) таңдау үшін басқа пайдаланушы интерфейстері қолданылады. Деректер қоры дайын болған кезде (оның барлық дерек құрылымдары мен басқа да қажетті компоненттері анықталғаннан кейін), ол әдетте бастапқы қолданба деректерімен толтырылады (деректер қорын бастапқылай орнату, бұл әдетте жеке жоба болып табылады; көп жағдайда жаппай енгізуді қолдайтын арнайы ДҚБЖ интерфейстерін пайдалану арқылы) оны пайдалануға беруден бұрын. Кейбір жағдайларда деректер қоры қолданба деректерінен бос күйде пайдалануға беріледі, ал деректер оның жұмыс істеу кезінде жинақталады. Деректер қоры құрылып, бастапқылай орнатылып, толтырылғаннан кейін оны күтіп ұстау қажет. Әртүрлі деректер қоры параметрлерін өзгерту қажет болуы мүмкін және деректер қорының өнімділігін жақсарту үшін оны баптау (тюнинг) қажет болуы мүмкін; қолданбаның дерек құрылымдары өзгертілуі немесе қосылуы мүмкін, қолданбаның мүмкіндіктерін кеңейту үшін жаңа байланысты қолданба бағдарламалары жазылуы мүмкін және т.б.

Сақтық көшірмелеу және қалпына келтіру

Кейде деректер қорын бұрынғы күйіне қайтару қажет болады (көптеген себептермен, мысалы, бағдарламалық қатеге байланысты деректер қоры зақымданған немесе қате деректермен жаңартылған жағдайларда). Мұны іске асыру үшін резервтік көшірме жасау операциясы белгілі уақыттарда немесе үздіксіз жүргізіледі, онда деректер қорының әрбір қажетті күйі (яғни оның деректерінің мәндері мен деректер базасының құрылымдарына енгізілуі) арнайы резервтік файлдарда сақталады (мұны тиімді ету үшін көптеген техникалар бар). Деректер қорының әкімшісі деректер қорын осы күйге қайтаруды шешкен кезде (мысалы, деректер қоры осы күйде болған белгілі бір уақытты көрсету арқылы), осы файлдар сол күйді қалпына келтіру үшін пайдаланылады.

Статикалық талдау

Бағдарламалық жасақтаманы тексеру үшін қолданылатын статикалық талдау әдістерін сұрау тілдерінің жағдайында да пайдалануға болады. Атап айтқанда, *Абстрактілік интерпретация аясы дұрыс жуықтау әдістерін қолдау мақсатымен реляциялық деректер базалары үшін сұрау тілдері саласына кеңейтілді. Сұрау тілдерінің семантикасы деректердің нақты доменінің тиісті абстракцияларына сәйкес өзгертілуі мүмкін. Реляциялық деректер базасы жүйелерінің абстракциясы көптеген қызықты қолданыстарға ие, әсіресе қауіпсіздік мақсатында, мысалы, егжей-тегжейлі кіруді бақылау, су таңбасы салу және т.б.

Жобалау және модельдеу

Деректер базасын жобалаушының бірінші міндеті – деректер базасында сақталатын ақпараттың құрылымын көрсететін тұжырымдамалық деректер моделін жасау. Бұл үшін жиі қолданылатын тәсіл – сурет құралының көмегімен нысандар арасындағы қатынас моделін әзірлеу. Тағы бір танымал тәсіл – Бірыңғай модельдеу тілі. Сәтті деректер моделі модельденетін сыртқы әлемнің ықтимал жағдайын дәл көрсетеді: мысалы, егер адамдар бірден көп телефон нөмірін иеленсе, бұл ақпаратты тіркеуге мүмкіндік береді. Жақсы тұжырымдамалық деректер моделін жобалау үшін қолданбалы сала жақсы түсінілуі керек; әдетте бұл ұйымға қызығушылық тудыратын нәрселер туралы терең сұрақтар қоюды қамтиды, мысалы «клиент сонымен қатар жеткізуші бола ала ма?», немесе «егер өнім екі түрлі қаптамада сатылатын болса, олар бір өнім бе, әлде екі түрлі өнім бе?» немесе «Егер ұшақ Нью-Йорктен Дубайға Франкфурт арқылы ұшса, бұл бір рейс пе, әлде екі (немесе тіпті үш) ме?» Осы сұрақтарға жауап беру арқылы нысандарға (клиенттер, өнімдер, рейстер, рейс сегменттері) және олардың қатынастары мен атрибуттарына қолданылатын терминологияны анықтауға болады. Тұжырымдамалық деректер моделін жасау кейде бизнес-процестерден немесе ұйымның жұмыс ағынын талдаудан алынған деректерді қамтиды. Бұл деректер базасында қандай ақпарат қажет екенін және нені алып тастау керектігін анықтауға көмектеседі. Мысалы, бұл деректер базасына тарихи деректерді, сондай-ақ ағымдағы деректерді сақтау қажет пе, жоқ па, шешуге көмектеседі. Пайдаланушылар қанағаттанған тұжырымдамалық деректер моделін жасағаннан кейін, келесі кезең – бұл деректер базасындағы тиісті деректер құрылымдарын іске асыратын схемаға аудару. Бұл процесс көбінесе логикалық деректер базасының дизайны деп аталады, ал нәтижесі – схема түрінде көрсетілген логикалық деректер моделі. Тұжырымдамалық деректер моделі (кем дегенде теорияда) деректер базасы технологиясын таңдауға тәуелсіз болса, логикалық деректер моделі таңдалған ДҚБЖ қолдайтын нақты деректер базасы моделінің шарттарымен беріледі. (Деректер моделі және деректер базасы моделі терминдері көбінесе бір-бірін алмастыра қолданылады, бірақ осы мақалада біз нақты деректер базасын жобалау үшін деректер моделін, ал осы жобаны білдіру үшін қолданылатын модельдеу белгісі үшін деректер базасы моделін қолданамыз). Жалпы мақсаттағы деректер базалары үшін ең танымал деректер базасы моделі – реляциялық модель, немесе нақтырақ айтқанда, SQL тілімен ұсынылған реляциялық модель. Бұл модельді пайдалана отырып логикалық деректер базасының дизайнын жасау процесі нормалдау деп аталатын әдістемелік тәсілді қолданады. Нормалдаудың мақсаты – әрбір элементарлық «факті» тек бір жерде ғана тіркелгенін қамтамасыз ету, осылайша енгізулер, жаңартулар және жоюлар автоматты түрде сәйкестікті сақтайды. Деректер базасын жобалаудың соңғы кезеңі – бұл белгілі бір ДҚБЖ-ге байланысты өнімділікке, кеңейтілуге, қалпына келтіруге, қауіпсіздікке және басқаларына әсер ететін шешімдерді қабылдау. Бұл физикалық деректер базасының дизайны деп аталады, ал нәтижесі – физикалық деректер моделі. Бұл кезеңдегі басты мақсат – деректердің тәуелсіздігі, яғни өнімділікті оңтайландыру мақсатында қабылданған шешімдер соңғы пайдаланушылар мен қосымшаларға көрінбеуі керек. Деректердің тәуелсіздігінің екі түрі бар: физикалық деректердің тәуелсіздігі және логикалық деректердің тәуелсіздігі. Физикалық жобалау негізінен өнімділік талаптарына негізделеді және күтілетін жұмыс жүктемесі мен қол жеткізу үлгілерін жақсы білуді және таңдалған ДҚБЖ ұсынатын мүмкіндіктерді терең түсінуді талап етеді. Физикалық деректер базасын жобалаудың тағы бір аспектісі – қауіпсіздік. Бұл деректер базасы нысандарына қол жеткізуді бақылауды анықтауды, сондай-ақ деректердің қауіпсіздігі деңгейлері мен әдістерін анықтауды қамтиды.

The first task of a database designer is to produce a conceptual data model that reflects the structure of the information to be held in the database. A common approach to this is to develop an entity–relationship model, often with the aid of drawing tools. Another popular approach is the Unified Modeling Language. A successful data model will accurately reflect the possible state of the external world being modeled: for example, if people can have more than one phone number, it will allow this information to be captured. Designing a good conceptual data model requires a good understanding of the application domain; it typically involves asking deep questions about the things of interest to an organization, like "can a customer also be a supplier? ", or "if a product is sold with two different forms of packaging, are those the same product or different products? ", or "if a plane flies from New York to Dubai via Frankfurt, is that one flight or two (or maybe even three)?". The answers to these questions establish definitions of the terminology used for entities (customers, products, flights, flight segments) and their relationships and attributes. Producing the conceptual data model sometimes involves input from business processes, or the analysis of workflow in the organization. This can help to establish what information is needed in the database, and what can be left out. For example, it can help when deciding whether the database needs to hold historic data as well as current data. Having produced a conceptual data model that users are happy with, the next stage is to translate this into a schema that implements the relevant data structures within the database. This process is often called logical database design, and the output is a logical data model expressed in the form of a schema. Whereas the conceptual data model is (in theory at least) independent of the choice of database technology, the logical data model will be expressed in terms of a particular database model supported by the chosen DBMS. (The terms data model and database model are often used interchangeably, but in this article we use data model for the design of a specific database, and database model for the modeling notation used to express that design). The most popular database model for general purpose databases is the relational model, or more precisely, the relational model as represented by the SQL language. The process of creating a logical database design using this model uses a methodical approach known as normalization. The goal of normalization is to ensure that each elementary "fact" is only recorded in one place, so that insertions, updates, and deletions automatically maintain consistency. The final stage of database design is to make the decisions that affect performance, scalability, recovery, security, and the like, which depend on the particular DBMS. This is often called physical database design, and the output is the physical data model. A key goal during this stage is data independence, meaning that the decisions made for performance optimization purposes should be invisible to end users and applications. There are two types of data independence: Physical data independence and logical data independence. Physical design is driven mainly by performance requirements, and requires a good knowledge of the expected workload and access patterns, and a deep understanding of the features offered by the chosen DBMS. Another aspect of physical database design is security. It involves both defining access control to database objects as well as defining security levels and methods for the data itself.

Зерттеу

Деректер базасы технологиясы 1960 жылдан бері академиялық ортада да, компаниялардың ғылыми-зерттеу топтарында да (мысалы, IBM Research) белсенді зерттеу нысаны болып табылады. Зерттеу қызметі теорияны және прототиптерді әзірлеуді қамтиды. Көзге түсетін зерттеу тақырыптарына модельдер, атомдық транзакциялар концепциясы, осыған байланысты бір уақытта орындалуды басқару техникалары, сұраныс тілдері және сұраныстарды оңтайландыру әдістері, RAID және тағы да басқалары жатады. Деректер базасын зерттеу саласында бірнеше арнайы академиялық журналдар (мысалы, ACM Transactions on Database Systems TODS, Data and Knowledge Engineering DKE) және жыл сайынғы конференциялар (мысалы, ACM SIGMOD, ACM PODS, VLDB, IEEE ICDE) бар.