Организация и управление данными в вычислительной технике.

Введение

Организованный сбор данных в вычислительной технике – вычислительная концепция.

В вычислительной технике база данных представляет собой организованную коллекцию данных или тип хранилища данных, основанный на использовании системы управления базами данных (СУБД) – программного обеспечения, которое взаимодействует с конечными пользователями, приложениями и самой базой данных для сбора и анализа данных. СУБД также включает в себя основные средства, предоставляемые для администрирования базой данных. Совокупность базы данных, СУБД и связанных с ними приложений может называться системой баз данных. Часто термин "база данных" также используется в широком смысле для обозначения любой из СУБД, системы баз данных или приложения, связанного с базой данных. Небольшие базы данных могут храниться в файловой системе, в то время как большие базы данных размещаются в компьютерных кластерах или облачных хранилищах. Проектирование баз данных охватывает как формальные методы, так и практические аспекты, включая моделирование данных, эффективное представление и хранение данных, языки запросов, безопасность и конфиденциальность чувствительных данных, а также вопросы распределенных вычислений, включая поддержку параллельного доступа и отказоустойчивость. Специалисты в области компьютерных наук могут классифицировать системы управления базами данных в соответствии с моделями данных, которые они поддерживают. Реляционные базы данных стали доминирующими в 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 разработала MRDS для Multics, а сейчас существует две новые реализации: Alphora Dataphor и Rel. Большинство других реализаций СУБД, обычно называемых реляционными, на самом деле являются СУБД SQL. В 1970 году Университет Мичигана начал разработку Информационной системы 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. Другим подходом к аппаратному обеспечению управления базами данных был ускоритель CAFS от ICL – аппаратный контроллер дисков с программируемыми функциями поиска. В долгосрочной перспективе эти усилия оказались в основном безуспешными, поскольку специализированные машины для баз данных не могли угнаться за стремительным развитием и прогрессом компьютеров общего назначения. Поэтому большинство современных систем управления базами данных представляют собой программные системы, работающие на универсальном аппаратном обеспечении с использованием стандартных средств хранения данных. Тем не менее, эта концепция до сих пор применяется в определенных областях некоторыми компаниями, такими как Netezza и Oracle (Exadata).

Конец 1970-х годов, SQL DBMS

IBM начала работу над прототипной системой, свободно основанной на концепциях Кодда, под названием System R в начале 1970-х годов. Первая версия была готова в 1974/75 годах, после чего началась разработка систем с несколькими таблицами, в которых данные можно было разделить таким образом, чтобы не все данные для записи (включая необязательные поля) хранились в одном большом блоке. Последующие многопользовательские версии были протестированы клиентами в 1978 и 1979 годах, к этому времени был добавлен стандартизированный язык запросов – SQL. Идеи Кодда зарекомендовали себя как работоспособные и превосходящие CODASYL, что побудило IBM разработать полноценную производственную версию System R, известную как SQL/DS, а затем Database 2 (IBM Db2). База данных Oracle (или просто Oracle) Ларри Эллисона началась с другого направления, основанного на публикациях IBM о System R. Хотя реализация Oracle V1 была завершена в 1978 году, Эллисон опередил IBM на рынке только с Oracle Version 2 в 1979 году. Стоунбрейкер использовал опыт, полученный при работе с INGRES, для разработки новой базы данных Postgres, которая теперь известна как PostgreSQL. PostgreSQL часто используется для глобальных критически важных приложений (регистраторы доменных имен org и info используют её в качестве основного хранилища данных, как и многие крупные компании и финансовые институты). В Швеции также была изучена работа Кодда, и в середине 1970-х годов в Уппсальском университете была разработана Mimer SQL. В 1984 году этот проект был выделен в независимое предприятие. Другая модель данных, модель «сущность-связь», появилась в 1976 году и приобрела популярность при проектировании баз данных, поскольку предлагала более понятное описание, чем более ранняя реляционная модель. Впоследствии конструкции модели «сущность-связь» были адаптированы как инструмент моделирования данных для реляционной модели, и различие между ними стало несущественным.

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-базы данных часто отличаются высокой скоростью, не требуют фиксированных схем таблиц, избегают операций соединения (join) за счет хранения денормализованных данных и предназначены для горизонтального масштабирования. В последние годы наблюдается высокий спрос на масштабно распределенные базы данных с высокой устойчивостью к разделению, но согласно теореме CAP, распределенной системе невозможно одновременно обеспечить согласованность, доступность и устойчивость к разделению. Распределенная система может удовлетворять любым двум из этих требований одновременно, но не всем трем. Поэтому многие NoSQL-базы данных используют так называемую eventual consistency (конечную согласованность), чтобы обеспечить как доступность, так и устойчивость к разделению при сниженном уровне согласованности данных. NewSQL — это класс современных реляционных баз данных, разработанных для обеспечения такой же масштабируемой производительности, как у систем NoSQL, при обработке транзакционных рабочих нагрузок (чтение-запись), сохраняя при этом использование SQL и гарантии ACID традиционных систем баз данных.

Случаи использования

Базы данных используются для поддержки внутренних операций организаций и обеспечения онлайн-взаимодействия с клиентами и поставщиками (см. корпоративное программное обеспечение). Базы данных применяются для хранения административной информации и более специализированных данных, таких как инженерные данные или экономические модели. Примеры включают в себя компьютеризированные библиотечные системы, системы резервирования авиабилетов, компьютеризированные системы учета запчастей и многие системы управления контентом, хранящие веб-сайты в виде набора веб-страниц в базе данных.

Применение

Внешнее взаимодействие с базой данных будет осуществляться посредством прикладной программы, которая обеспечивает интерфейс с СУБД. Это может быть как инструмент для работы с базой данных, позволяющий пользователям выполнять SQL-запросы в текстовом или графическом виде, так и веб-сайт, использующий базу данных для хранения и поиска информации.

Интерфейс программы

Программист будет реализовывать взаимодействие с базой данных (иногда называемой источником данных) посредством интерфейса прикладного программирования (API) или с использованием языка базы данных. Конкретный выбранный API или язык должен поддерживаться СУБД, возможно, косвенно через препроцессор или промежуточный API. Некоторые API стремятся быть независимыми от конкретной базы данных, ODBC является общеизвестным примером. Другие распространенные API включают JDBC и ADO.NET.

Хранение

Хранилище базы данных – это контейнер для физической реализации базы данных. Оно составляет внутренний (физический) уровень в архитектуре базы данных. Оно также содержит всю необходимую информацию (например, метаданные, "данные о данных" и внутренние структуры данных) для восстановления концептуального и внешнего уровней из внутреннего уровня при необходимости. Базы данных как цифровые объекты содержат три уровня информации, которые должны быть сохранены: данные, структура и семантика. Для обеспечения сохранности и долговечности базы данных необходимо надлежащее хранение всех трех уровней. Ответственность за помещение данных в постоянное хранилище обычно лежит на механизме базы данных, также известном как "механизм хранения". Хотя обычно доступ к СУБД осуществляется через базовую операционную систему (и часто с использованием файловых систем операционной системы в качестве посредника для организации хранения), свойства хранилища и параметры конфигурации имеют решающее значение для эффективной работы СУБД и, следовательно, тщательно поддерживаются администраторами баз данных. СУБД, находясь в работе, всегда имеет свою базу данных, размещенную в нескольких типах хранилищ (например, в памяти и во внешнем хранилище). Данные базы данных и дополнительная необходимая информация, возможно, в очень больших объемах, кодируются в биты. Данные обычно хранятся в структурах, которые значительно отличаются от представления данных на концептуальном и внешнем уровнях, но таким образом, чтобы оптимизировать (насколько это возможно) восстановление этих уровней при необходимости для пользователей и программ, а также для вычисления дополнительных типов необходимой информации из данных (например, при выполнении запросов к базе данных). Некоторые СУБД поддерживают указание кодировки символов, использованной для хранения данных, что позволяет использовать несколько кодировок в одной базе данных. Различные низкоуровневые структуры хранения баз данных используются механизмом хранения для сериализации модели данных, чтобы ее можно было записать на выбранный носитель. Такие методы, как индексирование, могут использоваться для повышения производительности. Традиционное хранение ориентировано на строки, но существуют также хранилища, ориентированные на столбцы, и корреляционные базы данных.

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.

Материализованные взгляды

Часто избыточность хранения используется для повышения производительности. Типичным примером является хранение материализованных представлений, состоящих из часто запрашиваемых внешних представлений или результатов запросов. Хранение таких представлений позволяет избежать дорогостоящих повторных вычислений при каждом обращении к ним. К недостаткам материализованных представлений относятся накладные расходы на их обновление для поддержания синхронизации с исходными обновленными данными базы данных, а также стоимость, связанная с избыточностью хранения.

Репликация

Иногда база данных использует избыточность хранения посредством репликации объектов базы данных (с одной или несколькими копиями) для повышения доступности данных (как для улучшения производительности одновременного доступа множества пользователей к одному и тому же объекту базы данных, так и для обеспечения отказоустойчивости в случае частичного сбоя распределенной базы данных). Обновления реплицированного объекта необходимо синхронизировать между его копиями. Во многих случаях реплицируется вся база данных.

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

При виртуализации данных, сами данные остаются в исходных местах, а доступ к ним в реальном времени обеспечивается для проведения аналитики из различных источников. Это может помочь в решении ряда технических проблем, таких как проблемы совместимости при объединении данных с разных платформ, снижении риска ошибок, вызванных некорректными данными, и обеспечении использования самых актуальных данных. Кроме того, избежание создания новой базы данных, содержащей персональную информацию, может упростить соблюдение требований по защите конфиденциальности. Однако, при использовании виртуализации данных, необходимо, чтобы все необходимые источники данных были доступны и работоспособны, поскольку локальной копии данных не создается, что является одним из основных недостатков данного подхода.

Безопасность

Безопасность баз данных охватывает все аспекты защиты содержимого базы данных, ее владельцев и пользователей. Она включает в себя защиту как от преднамеренного несанкционированного использования базы данных, так и от случайного доступа к ней со стороны неавторизованных сущностей (например, человека или компьютерной программы). Контроль доступа к базе данных определяет, кому (человеку или определенной компьютерной программе) разрешено получать доступ к какой информации в базе данных. Эта информация может включать в себя конкретные объекты базы данных (например, типы записей, отдельные записи, структуры данных), определенные операции над этими объектами (например, типы запросов или конкретные запросы), или конкретные пути доступа к ним (например, использование определенных индексов или других структур данных для доступа к информации). Контроль доступа к базе данных устанавливается специальным, уполномоченным (владельцем базы данных) персоналом с использованием специальных защищенных интерфейсов СУБД. Управление может осуществляться напрямую на индивидуальной основе, путем назначения привилегий пользователям и группам, или (в наиболее сложных моделях) путем назначения пользователей и групп ролям, которым затем предоставляются права доступа. Безопасность данных предотвращает несанкционированный просмотр или изменение данных в базе данных. С помощью паролей пользователям предоставляется доступ ко всей базе данных или к ее подмножествам, называемым "подсхемами". Например, база данных сотрудников может содержать все данные об отдельном сотруднике, но одна группа пользователей может быть авторизована только на просмотр данных о заработной плате, в то время как другим может быть разрешен доступ только к истории работы и медицинским данным. Если СУБД предоставляет возможность интерактивного ввода, обновления и запроса данных, это позволяет управлять персональными базами данных. Безопасность данных в целом направлена на защиту конкретных фрагментов данных как физически (т.е. от повреждения, уничтожения или удаления; см. физическую безопасность), так и от несанкционированной интерпретации данных или их частей для получения значимой информации (например, путем анализа последовательности битов для выявления действительных номеров кредитных карт; см. шифрование данных). Журналирование изменений и доступа фиксирует, кто обращался к каким атрибутам, какие изменения были внесены и когда они были сделаны. Службы ведения журналов позволяют проводить последующий криминалистический аудит базы данных, сохраняя записи о событиях доступа и изменениях. В некоторых случаях код на уровне приложения используется для записи изменений вместо сохранения их в базе данных. Может быть настроен мониторинг для обнаружения нарушений безопасности. Поэтому организациям необходимо серьезно относиться к безопасности баз данных из-за множества преимуществ, которые она обеспечивает. Организации будут защищены от нарушений безопасности и хакерских атак, таких как взлом брандмауэра, распространение вирусов и программы-вымогатели. Это помогает защитить важную информацию компании, которая ни при каких обстоятельствах не должна быть доступна посторонним.

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 описывает идеальные свойства транзакции базы данных: атомарность, согласованность, изолированность и надежность.

Миграция

База данных, созданная с использованием одной СУБД, не переносима в другую СУБД (то есть другая СУБД не может ее использовать). Однако в некоторых ситуациях возникает необходимость в переносе базы данных из одной СУБД в другую. Основные причины – экономические (разные СУБД могут иметь различные совокупные затраты на владение или ТСО), функциональные и операционные (разные СУБД могут обладать различными возможностями). Миграция подразумевает преобразование базы данных из одного типа СУБД в другой. Преобразование должно, по возможности, сохранить связанное с базой данных приложение (то есть все прикладные программы, использующие базу данных) в рабочем состоянии. Таким образом, концептуальный и внешний уровни архитектуры базы данных должны быть сохранены в процессе преобразования. Также может потребоваться сохранение некоторых аспектов внутреннего уровня архитектуры. Миграция сложной или крупной базы данных сама по себе может оказаться сложным и дорогостоящим (единовременным) проектом, что необходимо учитывать при принятии решения о миграции. Это справедливо, даже если существуют инструменты, облегчающие миграцию между конкретными СУБД. Обычно поставщик СУБД предоставляет инструменты для импорта баз данных из других распространенных СУБД.

Строительство, обслуживание и настройка

После проектирования базы данных для приложения следующим этапом является её создание. Обычно для этого выбирается подходящая универсальная СУБД. СУБД предоставляет необходимые пользовательские интерфейсы, используемые администраторами баз данных для определения структур данных приложения в рамках соответствующей модели данных СУБД. Другие интерфейсы используются для выбора необходимых параметров СУБД (например, параметров безопасности, параметров выделения памяти и т.п.). Когда база данных готова (определены все её структуры данных и другие необходимые компоненты), она обычно заполняется исходными данными приложения (инициализация базы данных, которая, как правило, является отдельным проектом; во многих случаях используются специализированные интерфейсы СУБД, поддерживающие массовую загрузку данных) перед началом её эксплуатации. В некоторых случаях база данных начинает работу пустой, а данные накапливаются в процессе её использования. После создания, инициализации и заполнения базы данных требуется её обслуживание. Различные параметры базы данных могут потребовать изменения, а также может потребоваться её настройка для повышения производительности; структуры данных приложения могут быть изменены или добавлены, могут быть разработаны новые связанные приложения для расширения функциональности и т.д.

Резервное копирование и восстановление

Иногда возникает необходимость вернуть базу данных в предыдущее состояние (по разным причинам, например, если база данных оказалась поврежденной из-за программной ошибки или была обновлена некорректными данными). Для этого периодически или непрерывно выполняется операция резервного копирования, в ходе которой каждое желаемое состояние базы данных (то есть значения ее данных и их представление в структурах данных базы данных) сохраняется в отдельных файлах резервных копий (существует множество способов эффективной реализации этого). Когда администратор базы данных принимает решение о восстановлении базы данных до этого состояния (например, указав желаемый момент времени, когда база данных находилась в этом состоянии), эти файлы используются для восстановления.

Статический анализ

Методы статического анализа для верификации программного обеспечения могут быть применены и в сценарии языков запросов. В частности, фреймворк *абстрактной интерпретации был расширен для области языков запросов к реляционным базам данных как способ поддержки надежных методов аппроксимации. Семантика языков запросов может быть адаптирована в соответствии с подходящими абстракциями конкретной области данных. Абстракция реляционных систем управления базами данных имеет множество интересных применений, особенно в целях безопасности, таких как детальный контроль доступа, водяные знаки и т.п.

Проектирование и моделирование

Первая задача дизайнера базы данных — создать концептуальную модель данных, отражающую структуру информации, хранящейся в базе данных. Распространенным подходом к этому является разработка модели «сущность-связь», часто с использованием инструментов для рисования. Другой популярный подход — это Унифицированный язык моделирования (UML). Успешная модель данных будет точно отражать возможное состояние моделируемого реального мира: например, если у человека может быть несколько телефонных номеров, она позволит зафиксировать эту информацию. Проектирование хорошей концептуальной модели данных требует глубокого понимания предметной области; обычно это включает в себя постановку вопросов, касающихся важных для организации аспектов, таких как: «может ли клиент одновременно быть поставщиком?», «если продукт продается в двух разных вариантах упаковки, это один и тот же продукт или разные продукты?» или «если самолет летит из Нью-Йорка в Дубай через Франкфурт, это один рейс или два (или, возможно, даже три)?». Ответы на эти вопросы определяют терминологию, используемую для сущностей (клиентов, продуктов, рейсов, сегментов рейсов), их связей и атрибутов. Создание концептуальной модели данных иногда включает в себя учет бизнес-процессов или анализ рабочих процессов в организации. Это помогает определить, какая информация необходима в базе данных, а какую можно исключить. Например, это может помочь решить, нужно ли хранить в базе данных исторические данные, помимо текущих. После создания концептуальной модели данных, удовлетворяющей пользователей, следующим этапом является ее преобразование в схему, реализующую соответствующие структуры данных в базе данных. Этот процесс часто называют логическим проектированием базы данных, а результатом является логическая модель данных, представленная в виде схемы. В то время как концептуальная модель данных (по крайней мере, в теории) не зависит от выбора технологии базы данных, логическая модель данных будет выражена в терминах конкретной модели базы данных, поддерживаемой выбранной СУБД. (Термины «модель данных» и «модель базы данных» часто используются как взаимозаменяемые, но в этой статье мы используем «модель данных» для проектирования конкретной базы данных и «модель базы данных» для обозначения нотации моделирования, используемой для выражения этого проекта). Наиболее популярной моделью базы данных для баз данных общего назначения является реляционная модель, или, точнее, реляционная модель, представленная языком 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).