Что такое «база данных»?

14

В этом вопросе было много дискуссий: какие технологии баз данных используют крупные поисковые системы?

Столько дискуссий, что это смутило меня. Итак ... что такое база данных? Являются ли только реляционные базы данных "базами данных"? Являются ли объектно-ориентированные базы данных "базами данных"? Есть ли какая-либо система, которая позволяет мне хранить и извлекать информацию (например, карту, список и т. Д.) В базе данных?

Или база данных должна хранить / извлекать информацию, а также иметь некоторые функции администрирования, такие как пользователи и привилегии? Была ли dBase III плюс база данных, поскольку она не была действительно реляционной?

woliveirajr
источник
@ypercube: «Благодаря своей способности одновременно открывать и манипулировать несколькими файлами, содержащими связанные данные, Эштон-Тейт помечала dBase как« реляционная база данных », хотя она не соответствовала критериям, определенным реляционной моделью д-ра Эдгара Ф. Кодда; можно назвать языком разработки приложений и интегрированной навигационной системой управления базами данных, на которую влияют реляционные концепции ". из Википедии
woliveirajr
3
Я не верю, что база данных должна быть «управляемой», чтобы быть базой данных.
Аарон Бертран

Ответы:

9

Это отличный вопрос и набор отличных ответов. Я думаю, что одна вещь, которая отсутствует в обсуждении, это ответ, который углубляется в различие между базой данных и системой управления базами данных (СУБД). Мне нравится определение базы данных, которое Акула предоставила на dictionary.com. Я думаю, что это действительно показывает необходимость различия между базой данных и СУБД. База данных представляет собой «комплексную коллекцию связанных данных, организованную для удобного доступа». Вторая часть этого определения, которая гласит «обычно в компьютере», - это то, где находится различие. Если он хранится на компьютере, он может храниться или не храниться в СУБД. Может храниться в файловой системе ОС. Может храниться в проприетарной файловой системе. Таким образом, я согласен с FrustratedWithFormsDesigner, что карточный каталог является «базой данных» (ну, может быть - это всеобъемлющее и связанное? Подробнее об этом позже). Это просто происходит в картотеке. В современном мире наиболее «полные» коллекции связанных данных организованы для удобного доступакоторые хранятся на компьютере, так что я не согласен с акулой , что это жаль Dictionary.com добавил , что часть. Я думаю, что это абсолютно правильно - как определение «базы данных».

Итак, как мы определяем СУБД? Я вернулся на dictionary.com и нашел это :

«Набор программ, которые обычно управляют большими структурированными наборами постоянных данных, предлагая многопользовательские возможности специальных запросов. Они широко используются в бизнес-приложениях».

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

Используя это определение, я думаю, что ясно, что СУБД должна предоставлять модель данных , которая является способом, которым данные организованы для представления пользователю. Три общие модели: иерархическая (IMS), сетевая (IDMS) и реляционная (DB2, Oracle, SQL-Server и т. Д.). Существует также модель OO (OODBMS). Только реляционная модель сегодня имеет широкую применимость. Другие модели все еще используются, но только в нишевых ситуациях. СУБД также должна обеспечивать другие упомянутые функции. Я бы назвал их в совокупности функциями или возможностями управления данными.

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

Специалист по данным должен понимать все эти инструменты для хранения данных и какие классы проблем они подходят для того, чтобы выбрать правильный инструмент для работы, точно так же, как генеральный подрядчик должен знать, какой из его или ее строительных инструментов является правильный инструмент для работы. Ни один инструмент не является хорошим или плохим сам по себе. Хорошо, если это подходит для решения важной проблемы.

В заключение я отмечу два других ключевых различия в определении как базы данных, так и СУБД, которые могут быть упущены при обсуждении. Определение базы данных включает « полный сбор связанных данных». Определение СУБД включает в себя «управлять большими структурированнымилучше было бы использовать MS Access или какую-либо другую реляционную СУБД. Таким образом, возможно, карточный каталог, в конце концов, не является базой данных, поскольку, будучи всеобъемлющим (он содержит записи обо всех книгах в библиотеке), он не связан, поскольку содержит только информацию о книгах, а не полную связанную информацию об авторах, издателях, и т.п.

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

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

Тод эверетт
источник
1
Хороший пост. В списке Крейга, я думаю, есть еще несколько слоев, которые вы должны рассмотреть. Хранение и поиск не должны происходить непосредственно над СУБД. Вы, безусловно, могли бы масштабировать данные, которые хранятся, скажем, в SQL Server, не делая SQL Server непосредственно ответственным за ответы на запросы пользователей. Существуют все виды решений для кэширования среднего уровня и данных, которые могут помочь СУБД без необходимости замены СУБД. В своей предыдущей работе я использовал десятки экземпляров Express на веб-серверах, чтобы уменьшить нагрузку на основной SQL Server - работали частые, а не вытягивающие операции.
Аарон Бертран
Спасибо Аарон. Мой недостаток опыта работы с приложениями вне традиционных бизнес-приложений показывает. Я видел несколько постов, например Брента Озара, о решениях для кэширования данных, но никогда не видел ни одного в использовании. Спасибо за ваш пример на вашем предыдущем опыте. Я обязательно добавлю эту концепцию наслоения над СУБД, чтобы обеспечить масштабирование без потери преимуществ СУБД для панели инструментов!
Тодд Эверетт
Таким образом, БД IMS - это СУБД, а Кассандра - нет. Извините, но с уважением не согласен.
Майкл Грин
9

Я процитирую Dictionary.com , поскольку я принимаю это как значение базы данных:

всеобъемлющий сбор связанных данных, организованных для удобного доступа, как правило, на компьютере.

Согласно этому определению, вы можете рассматривать базу данных как угодно, от полноценной СУБД (SQL Server, Oracle и т. Д.) До простого плоского файла. Если он хранит данные, технически он может считаться базой данных.

Теперь, как и большинство вещей в нашем современном мире, есть общепринятый смысл имени. И в случае базы данных , это будет варьироваться от человека к человеку. Многие люди думают о базе данных исключительно как о сущности, управляемой системой данных.

Стоит отметить комментарий @ FrustratedWithFormsDesigner:

Карточные каталоги также будут учитываться, если вы удалите «... обычно на компьютере».

Я согласен с этим утверждением и не обязательно думаю, что база данных должна жить на «компьютере» или каком-либо электронном устройстве. Карточный каталог - прекрасный пример не компьютеризированной базы данных.

Томас Стрингер
источник
8

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

Я думаю, что определение менялось с течением времени, и сравнение словаря.com с вики с работами различных специалистов по базам данных за последние 30 лет даст множество определений. И определение будет продолжать развиваться, а также.

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

Очевидно, что некоторые люди получают довольно откровенные откровения, если вы даже придете к выводу, что BigTable (или NoSQL, или hadoop) является «базой данных», и утверждают, что их вызов как таковой даст - особенно новичкам - большую надежду на бесконечную производительность, бессмертие. и единороги. В то время как обычно вы просто подразумеваете, что это место, где данные хранятся и извлекаются, без каких-либо гарантий относительно того, что делает фактическая реализация, реляционная или нет, или вы могли бы создать такую ​​вещь самостоятельно, когда скучно в воскресенье днем.

Я признаю, что я съеживаюсь, когда люди говорят о реляционной базе данных и называют строки «записи» или столбцы «полями». Но хотя меня это немного раздражает, я не злюсь и не пытаюсь исправить их - какой в ​​этом смысл? Я понял, что они имели в виду, даже если они не на 100% точны.

Аарон Бертран
источник
5

Это может быть очень общее, просто набор данных и структур. Система управления базой данных может быть такой же простой, как файловая система, или такой же сложной, как федеративная система, такая как DNS.

Обычно при современном использовании, когда кто-то говорит «база данных», он подразумевает как хранилище данных, так и структуры и сопутствующую систему управления базами данных, и поскольку было проделано так много теоретической работы над основами реляционных баз данных, они все еще являются самыми популярными, поэтому что часто, когда кто-то говорит «база данных», он часто подразумевает реляционную базу данных.

С ростом NoSQL / нереляционных баз данных термин «база данных» вернулся к более общему и потенциально более двусмысленному, поскольку нельзя предположить общую модель для понимания данных.

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

Кейд Ру
источник
2

Я работал в Ashton-Tate во время разработки dBASE Direct / 36 и dBASE IV, используя свои знания dBASE III Plus для написания небольшой программы, помогающей в тестировании dBASE Direct / 36 (интерфейс для IBM System / 36 Mini Computer). Нам пришлось делать бинарные операторы load и call в SQL-таблицах System / 36, что требовало повторного ввода одних и тех же операторов «load» и «call» при изменении имен таблиц и имен полей при отправке, чтобы получить данные из каждой записи или группа из нескольких записей в зависимости от объема запроса. dBASE III Plus, язык программирования баз данных, позволил мне создать файл 'dbldot.prg', который изменил подсказку из одной точки на двойную точку, так как я разработал индикатор того, что система находилась в режиме извлечения SQL, а также текст ниже командной строки, которая сказала:

В то время dBASE был языком программирования баз данных или, точнее, языком программирования, который позволял манипулировать записями данных. Запись представляла собой группу полей, содержащих данные для одного отдельного элемента, таких как люди LAST_NAME, FIRST_NAME, ADDRESS, CITY, ST, ZIP, PLUS_FOUR, SSN и т. Д. Эти структуры были позже представлены в таблицах и организованы в строки и столбцы строка - отдельная запись, а столбец - данные в серии записей для каждого имени поля. Таким образом, пользователь может легко сортировать по имени поля, чтобы сортировать и группировать записи по определенным общим полям, таким как CITY, ST, ZIP и т. Д.

Язык dBASE позволил пользователю или программисту манипулировать данными, выполнять сортировку, отображать таблицы, записи и выполнять вычисления (Y2K был далеко, но даты должны были быть преобразованы в YYYYMMDD, чтобы отсортировать введенные данные MM-DD-YYYY, что можно сделать с помощью DtoC и CtoD (дата в символ, символ в дату)). Без языка dBASE файлы данных были бы просто серией записей (строк) с общими полями (столбцами).

Реляционная база данных - это термин, используемый для перекрестной ссылки нескольких баз данных (таблиц) на другую, которая содержала различную информацию, но содержала одно или несколько общих полей. Например, база данных под названием «Адреса» содержит «LNAME», «FNAME», «ADDRESS», «CITY», «ST», «ZIP», «SSN». Другая база данных под названием «CHECKING» содержит «ACCOUNT_NO», «ROUTING_NO», «CUSTLAST», «CUSTFIRST», «DOB», «SSNO», «CUST_NO». Хотя имена полей различны, некоторые из них содержат одну и ту же информацию, которую можно связать друг с другом, чтобы связать данные из одной базы данных с данными другой, скажем, для отправки выписок клиентам банка, используя поля имени и фамилии и номера SS для связи данных, извлекая адрес клиента из одной базы данных и информацию об учетной записи для помещения в выписку из другой. Затем, в более широком масштабе, может быть реализована функция слияния почты для выполнения этих действий для каждого отдельного клиента в базе данных ADDRESS, извлечения соответствующей информации об учетной записи каждого клиента, персонализации выписки, печати и адресации каждого до перехода к следующему. запись или клиент в базе данных.

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

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

По сути, я всегда это понимал в течение многих лет тестирования программного и аппаратного обеспечения, которое началось с dBASE II еще в 1984 году.

HoundCat
источник
2

Основной документ Кодда был назван реляционной моделью данных для крупных общих банков данных . То, что он назвал «банком данных», мы бы назвали базой данных.

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

Майкл Грин
источник
1

Из Основы проектирования баз данных 7-е изд. (стр. 5),

База данных представляет собой совокупность связанных данных.

Они продолжают говорить, что общее использование более ограничено,

База данных имеет следующие неявные свойства:

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

Ни в одном из определений база данных не является явно «реляционной» в каком-либо смысле, однако часто это предполагается, потому что отрасль насыщена администраторами баз данных одного конкретного типа и, возможно, все самое современное программное обеспечение СУБД является реляционным. Из словаря реляционных баз данных

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

Последний пункт несколько важен, и мне также нравится различие между СУБД / СУБД и самой базой данных.

Эван Кэрролл
источник