Для чего нужна субд
Что такое СУБД. Подробное описание для начинающих
Приветствую Вас нас сайте Info-Comp.ru! Сегодня я максимально просто, специально для начинающих, попытаюсь рассказать Вам о том, что такое СУБД, и для чего это нужно.
Что такое СУБД
Итак, давайте сразу начнем с расшифровки, что же такое СУБД.
СУБД – это система управления базами данных.
Иными словами, СУБД относится к сфере компьютерных баз данных.
Однако, чтобы понять, чем по своей сути является СУБД и для чего нужна эта система, необходимо начать с рассмотрения понятия базы данных.
Что такое база данных
Обычно под базой данных принято понимать любой набор информации, который хранится определенным образом, и этой информацией можно воспользоваться.
Однако если говорить о компьютерных базах данных, то здесь, конечно же, речь идет о так называемых реляционных базах данных.
Реляционная база данных – это упорядоченная информация, связанная между собой определёнными отношениями.
Логически такая база данных представлена в виде таблиц, в которых и хранится вся эта информация.
Физически база данных представляет собой, конечно же, обычные файлы, созданные в специальном формате.
И здесь возникает вопрос, если база данных — это файлы, созданные в специальном формате, то как создать такие файлы и редактировать их?
Для этого, как Вы понимаете, нужен специальный инструмент, т.е. программа, которая могла бы создавать базы данных и управлять ими, иными словами, работать с файлами базы данных.
Такой программой как раз и выступает СУБД, т.е. система управления базами данных.
Какие бывают СУБД
На самом деле СУБД — это некая разновидность программ, иными словами, существует достаточно много различных СУБД, как платных, так и бесплатных.
Что такое SQL
Каждая СУБД хранит файлы базы данных по-своему, т.е. в своем собственном формате, однако для того чтобы нам с Вами было легче управлять данными в базе данных был разработан специальный язык, который является стандартом и он позволяет нам, независимо от того в какой СУБД создана база данных, манипулировать данными в этой базе данных. Этот язык назвали SQL.
SQL (Structured Query Language) — язык структурированных запросов, с помощью него пишутся специальные запросы к базе данных с целью получения данных из базы данных или для манипулирования этими данными.
Язык SQL – как было уже отмечено, это стандарт, он реализован во всех реляционных базах данных, таким образом, если Вы знаете язык SQL, то Вы можете работать с данными в любой системе управления базами данных.
Однако у каждой СУБД, конечно же, есть расширение этого стандарта, для того чтобы, например, полноценно программировать, получать системную информацию, упрощать SQL запросы и инструкции.
Поэтому, если Вам нужно будет разрабатывать какую-нибудь бизнес логику в базе данных, писать сложные аналитические запросы на выборку, или обычные запросы, но в более упрощенном варианте, то Вам обязательно стоит учитывать, в какой СУБД Вы будете работать, для того чтобы изучить расширение языка SQL конкретно этой СУБД, так как и синтаксис, и возможности этих расширений, конечно же, отличаются.
Среди всех СУБД по функциональности и популярности можно выделить следующие системы.
Microsoft SQL Server
Microsoft SQL Server – это система управления базами данных от компании Microsoft. Она очень популярна в корпоративном секторе, особенно в крупных компаниях.
Microsoft SQL Server – это очень функциональная СУБД, и она, конечно же, распространяется платно. Однако у SQL Server есть редакция Express, которую можно использовать абсолютно бесплатно, например, для обучения или для разработки приложений, которые будут обрабатывать данные на небольших серверах (размером до 10 ГБ).
В Microsoft SQL Server для программирования в базах данных используется расширение языка SQL – Тransact-SQL, сокращенно T-SQL.
Oracle Database
Oracle Database – это система управления базами данных от компании Oracle. Это еще одна очень функциональная СУБД, которая также популярна среди крупных компаний. Возможности Oracle Database и Microsoft SQL Server сопоставимы, поэтому они являются серьезными конкурентами друг другу, и стоимость их полнофункциональных версий очень высокая.
В Oracle Database используется язык PL/SQL (Procedural Language / Structured Query Language) — это процедурное расширение языка SQL, разработанное компанией Oracle.
MySQL
MySQL – это система управления базами данных также от компании Oracle, но только она распространяется бесплатно. MySQL получила очень широкую популярность в интернете, так как именно на MySQL работают чуть ли не все web-сайты, иными словами, большинство сайтов в интернете используют эту СУБД как средство хранения данных.
PostgreSQL
PostgreSQL – эта система управления базами данных также является бесплатной, и она очень популярна и функциональна.
В PostgreSQL используется язык PL/pgSQL – это процедурное расширение языка SQL.
Выводы
В заключение давайте подведем итог.
СУБД (система управления базами данных) – это разновидность программ, с помощью которых создаются и управляются базы данных.
Надеюсь, я понятно ответил на вопрос «что такое СУБД» и для чего это нужно. А также надеюсь, что материал был Вам интересен и полезен.
На сегодня это все, удачи Вам, пока!
Заметка! Если Вас интересует язык SQL, то рекомендую почитать книгу «SQL код» – это самоучитель по языку SQL для начинающих программистов. В ней язык SQL рассматривается как стандарт, чтобы после прочтения данной книги можно было работать с языком SQL в любой системе управления базами данных.
Системы управления базами данных
Система управления базами данных (СУБД) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных.
Основные функции СУБД
Обычно современная СУБД содержит следующие компоненты:
Классификации СУБД
По модели данных
Иерархические
Используется представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.
Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект более близкий к корню) к потомку (объект более низкого уровня), при этом возможна ситуация, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один предок. Объекты, имеющие общего предка, называются близнецами (в программировании применительно к структуре данных дерево устоялось название братья).
Иерархической базой данных является файловая система, состоящая из корневого каталога, в котором имеется иерархия подкаталогов и файлов.
Примеры: Caché, Google App Engine Datastore API.
Сетевые
Сетевые базы данных подобны иерархическим, за исключением того, что в них имеются указатели в обоих направлениях, которые соединяют родственную информацию.
Реляционные
Практически все разработчики современных приложений, предусматривающих связь с системами баз данных, ориентируются на реляционные СУБД. По оценке Gartner в 2013 году рынок реляционных СУБД составлял 26 млрд долларов с годовым приростом около 9%, а к 2018 году рынок реляционных СУБД достигнет 40 млрд долларов. В настоящее время абсолютными лидерами рынка СУБД являются компании Oracle, IBM и Microsoft, с общей совокупной долей рынка около 90%, поставляя такие системы как Oracle Database, IBM DB2 и Microsoft SQL Server.
Объектно-ориентированные
Управляют базами данных, в которых данные моделируются в виде объектов, их атрибутов, методов и классов.
Этот вид СУБД позволяет работать с объектами баз данных так же, как с объектами в программировании в объектно-ориентированных языках программирования. ООСУБД расширяет языки программирования, прозрачно вводя долговременные данные, управление параллелизмом, восстановление данных, ассоциированные запросы и другие возможности.
Объектно-реляционные
Этот тип СУБД позволяет через расширенные структуры баз данных и язык запросов использовать возможности объектно-ориентированного подхода: бъекты, классы и наследование.
Зачастую все те СУБД, которые называются реляционными, являются, по факту, объектно-реляционными.
В данном курсе мы будем, в первую очередь, гооврить об этом виде СУБД.
Примеры: PostgreSQL, DB2, Oracle, Microsoft SQL Server.
По степени распределённости
По способу доступа к БД
Файл-серверные
В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера. Недостатки: потенциально высокая загрузка локальной сети; затруднённость или невозможность централизованного управления; затруднённость или невозможность обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Применяются чаще всего в локальных приложениях, которые используют функции управления БД; в системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками на БД.
На данный момент файл-серверная технология считается устаревшей, а её использование в крупных информационных системах — недостатком.
Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.
Клиент-серверные
Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу. Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность.
Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.
Встраиваемые
Встраиваемая СУБД — СУБД, которая может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Физически встраиваемая СУБД чаще всего реализована в виде подключаемой библиотеки. Доступ к данным со стороны приложения может происходить через SQL либо через специальные программные интерфейсы (API).
Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.
Стратегии работы с внешней памятью
Такая стратегия позволяет избежать частого обмена с внешней памятью и значительно увеличить эффективность работы СУБД.
Что такое База Данных (БД)
База данных — это место для хранения данных. Используется в том числе в клиент-серверной архитектуре. Это все интернет-магазины, сайты кинотеатров или авиабилетов. Вы делаете заказ, а система сохраняет ваши данные в базе.
В этот статье я на простых примерах расскажу, что такое база данных и как она выглядит. А потом поясню некоторые термины из конкретной (реляционной) базы. Те, с которыми вы почти наверняка столкнетесь на работе.
Статья рассчитана на начинающих тестировщиков или аналитиков, то есть тех, кто будет работать с базой, но не на супер-глубоком уровне. Она для тех, кто только входит в мир ИТ, и многого не знает. Она объясняет, что это за звено в клиент-серверной архитектуре такое, и зачем оно нужно.
Содержание
Что такое база данных
База данных — хранилище, куда приложение складывает свои данные. Если приложение небольшое, отдельная база не нужна. Но потом это становится удобнее и выгоднее с точки зрения памяти.
Катя решила открыть свой магазинчик. Она нашла хорошую марку обуви, которую «днем с огнем» не сыскать в ее городе. Заказала оптовую партию и стала потихоньку распродавать через знакомых. Пришлось освободить половину шкафа под коробки, но вроде всё поместилось.
Обувь хорошая, в розницу заказывать в других местах невыгодно — и вот уже у Кати есть постоянные клиенты, которые приводят друзей. Как только какая-то пара заканчивается, Катя делает новый заказ.
Но покупатели хотят новинок, разных размеров. Да и самих покупателей становится все больше и больше. В шкаф коробки уже не влезают!
Теперь, если покупатель просит определенную пару, Катьке сложно её найти. Пока коробок было мало, она помнила наизусть, где что лежит. А теперь уже нет, да и все попытки организовать систему провалились. Места мало, да и детки любят с коробками поиграть.
Тогда Катька решила арендовать складское помещение. И вот теперь красота! Не надо теснить своих домашних, дома чисто и свободно! И на складе место есть, появилась система — тут босоножки, тут сапоги.
Чем больше объемы производства, тем больше нужно места. Если в начале пути склад не нужен, всё поместится дома, то потом это будет оправданно.
То же самое и в приложениях. Если приложение маленькое, то все данные можно хранить в памяти. Но учтите, что это память на вашем компьютере, вашем телефоне. И чем больше данных туда пихать, тем медленнее будет работать программа.
Место в памяти ограничено. Поэтому когда данных много, их нужно куда-то сложить. Можно писать в файлики, а можно сохранять информацию в базу данных (сокращенно БД). Выбор за вами. А точнее, за вашим разработчиком.
Как она выглядит
Да примерно как excel-табличка! Есть колонки с заголовками, и информация внутри:
Это называется реляционная база данных — набор таблиц, хранящихся в одном пространстве.
Что за пространство? Ну вот представьте, что вы храните все данные в excel. Можно запихать всю-всю-всю информацию в одну огро-о-о-о-мную таблицу, но это неудобно. Обычно табличек несколько: тут информация по клиентам, там по заказам, а тут по адресам. Эти таблицы удобно хранить в одном месте, поэтому кладем их в отдельную папочку:
Так вот пространство внутри базы данных — это та же самая папочка в винде. Место, куда мы сложили свои таблички, чтобы они все были в одном месте.
Пример базы Oracle
Цель та же — выделить отдельное место, чтобы у вас не была одна большая свалка:
заходишь в папку в винде → видишь файлики только из этой папки
заходишь в пространство → видишь только те таблицы, которые в нем есть
Хранение данных в виде табличек — это не единственно возможный вариант. Вот вам для примера запись из таблицы в системе Users. Там используется MongoDB база данных, она не реляционная. Поэтому вместо таблички «словно в excel» каждая запись хранится в виде объекта, вот так:
А еще есть файловые базы — когда у вас вся информация хранится в файликах. Да-да, простых текстовых файликах!
Почитать о разных видах баз данных можно в википедии. Я не буду в этой статье углубляться в эту тему, потому что моя задача — объяснить «что это вообще такое» для ребят, которые базу в глаза не видели. А на работе они скорее всего столкнутся именно с реляционной базой данных, поэтому о ней и речь.
Как получить информацию из базы
Нужно записать свой запрос в понятном для базы виде — на SQL. SQL (Structured Query Language) — язык общения с базой данных. В нем есть ключевые слова, которые помогут вам сделать выборку:
select — выбери мне такие-то колонки.
from — из такой-то таблицы базы.
where — такую-то информацию.
Например, я хочу получить информацию по клиенту «Назина Ольга». Составляю в уме ТЗ:
В дословном переводе:
Комментарии в Oracle/PLSQL — мой перевод остается работающим запросом, потому что я убрала «лишнее» в комментарии
Если бы у меня была не база данных, а простые excel-файлики, то же действие было бы:
Открыть файл с нужными данными (clients)
Поставить фильтр на колонку «ФИО» — «Назина Ольга».
То есть нам в любом случае надо знать название таблицы, где лежат данные, и название колонки, по которой фильтруем. Это не что-то страшное, что есть только в базе данных. То же самое есть в простом экселе.
Бывают запросы и сложнее — когда надо достать данные не из одной таблицы, а из разных. В базе это будет выглядеть даже лучше, чем в эксельке. В экселе вам нужно открыть 1-2-3 таблицы и смотреть в каждую. Неудобно.
А в базе данных вы внутри запроса SQL указываете, какие колонки из каких таблиц вам нужны. И результат запроса их отрисовывает. Скажем, мы хотим увидеть заказ, который сделал клиент, ФИО клиента, и его номер телефона. И всё это в разных таблицах! А мы написали запрос и увидели то, что нам надо:
id_order
order (таблица order)
fio (таблица client)
phone (таблица contacts)
И пусть в таблице клиентов у нас будет 30 колонок, а в таблице заказов 50, в результате выборки мы видим ровно 4 запрошенные. Удобно, ничего лишнего!
Конечно, написать такой запрос будет немного сложнее обычного селекта. Это уже select join, почитать о нем можно тут. И я рекомендую вам его изучить, потому что он входит в «базовое знание sql», которое требуется на собеседованиях.
Результаты выборки можно группировать, сортировать — это следующий уровень сложности. См раздел «статьи и книги по теме» для получения большей информации.
Как связать данные между собой
Вот например, у нас есть интернет-магазин по доставке пиццы. Так выглядит его база данных:
В таблице «client» лежат данные по клиентам: ФИО, пол, дата рождения и т.д.
last_name
first_name
birthdate
В таблице «orders» лежат данные по заказам. Что заказали (пиццу, суши, роллы), когда, насколько довольны доставкой?
order
addr
date
time
Роллы «Филадельфия» и «Канада»
Пицца 35 см, роллы комбо 1
Пицца с сосиками по краям
Комбо набор 3, обед №4
Но как понять, где чей был заказ? Сколько раз заказывал Вася, а сколько Алина?
Тут есть несколько вариантов:
1. Запихать все данные в одну таблицу: тут и заказы, и информация по клиентам. В целом удобно, открыл табличку и сразу видишь — ага, это Васин заказ, а это Машин.
Таблица все растет и растет, в итоге получается просто огромной! А когда данных много, легкость чтения пропадает, придется листать до нужной колонки.
Поиск будет работать медленнее. Чем меньше информации в таблице, тем быстрее поиск. Когда у нас много строк, количество колонок становится существенным.
Много дублей — один человек может сделать хоть сотню заказов. И вся информация по нему будет продублирована сто раз. Неоптимальненько!
Чтобы избежать дублей, таблицы принято разделять:
Новые объекты отдельно
Но надо при этом их как-то связать между собой, мы ведь всё еще хотим знать, чей конкретно был заказ. Для связи таблиц используется foreign key, внешний ключ.
Нам надо у заказа сделать отметку о клиенте. Значит, таблица «orders» будет ссылаться на таблицу «clients». Ключ можно поставить на любую колонку таблицы (в некоторых базах колонка должна быть уникальной, сначала её нужно такой указать). Какую бы выбрать?
Можно ссылаться на имя. А что, миленько, в таблице заказов будем сразу имя видеть! Но минуточку. А если у нас два клиента Ивана? Или три Маши? Десять Саш. Ну вы поняли =) И как тогда разобраться, где какой клиент? Не подходит!
Можно вешать foreign key на несколько колонок. Например, на фамилию + имя, или фамилию + имя + отчество. Но ведь и ФИО бывают неуникальные! Что тогда? Можно добавить в связку дату рождения. Тогда шанс ошибиться будет минимален, хотя и такие ребята существуют. И чем больше клиентов у вас будет, тем больше шанс встретить дубликат.
А можно не усложнять! Вместо того, чтобы делать внешний ключ на 10 колонок, лучше создать в таблице клиентов primary key, первичный ключ. Первичный ключ отвечает за то, чтобы каждое значение в поле было уникальным, никаких дублей. При попытке добавить в таблицу запись с неуникальным первичным ключом получаешь ошибку:
Здесь ключ — «id_order»
Вот на него и нужно ссылаться! Обычно таким ключом является ID, идентификатор записи. Его можно сделать автоинкрементальным — это значит, что он генерируется сам по алгоритму «прошлое значение + 1».
Например, у нас гостиница для котиков. Это когда хозяева едут в отпуск, а котика оставить не с кем — оставляем в гостинице!
Для чего нужна субд
Каталог СУБД-решений и проектов доступен на TAdviser.
Содержание
Чем крупнее компания, чем дольше она существует на рынке, тем больше данных скапливается в ее архивах. Причем, в соответствии с реалиями сегодняшнего дня, вся информация хранится в электронной форме. По данным исследования Aberdeen Group, три года назад в крупных компаниях объемы хранимой информации увеличивались на 32% ежегодно. Сегодня бизнес-аналитика оперирует уже многотерабайтными объемами данных, а сами хранилища отчетливо перемещаются на облачные платформы.
Однако какая бы бесценная для бизнеса информация не хранились на серверах компании, она должна соответствовать нескольким критериям, так как если данные заносятся бессистемно и хранятся в разных форматах – польза от затраченных для этого ресурсов весьма сомнительна.
СУБД представляет собой набор программ, которые в общей сложности управляют организацией, хранением данных в БД. В целом такие системы классифицируются в зависимости от их структуры данных и их типов. СУБД принимает запросы прикладных программ и инструктирует операционную систему для передачи соответствующей информации. Новые категории данных, могут быть добавлены в БД без нарушения существующей схемы. Организации могут использовать один вид СУБД для осуществления ежедневных операций, а затем размещать необходимую информацию на другой машине, которая работает с другой системой управления, более подходящей для случайных запросов и анализа. Серверами резервного копирования баз данных, как правило, являются многопроцессорные системы с большим объемом ОЗУ и крупными дисковыми RAID-массивами. СУБД фактически является сердцем большинства приложений для работы с БД.
Аутсорсинг СУБД
2020: В каких случаях нужно передавать на аутсорсинг СУБД и бизнес-приложения
В апреле 2020 года директор центра технического консалтинга РДТЕХ Павел Шмелев перечислил основные плюсы аутсорсинга и рассказал, зачем компании отдают на сторону сопровождение собственных СУБД. Подробнее здесь.
Каким требованиям должна отвечать современная СУБД?
Информационное хранилище должно постоянно пополняться новыми данными в соответствии с ритмом жизни компании, это же касается и формирование новых категорий учета.
При этом вносить информацию должен иметь возможность любой новый сотрудник. То же касается и обслуживания данной инфраструктуры со стороны системного администратора, формирования новых выборок данных со стороны аналитиков с разным уровнем допуска к информации и с разными профилями анализируемых данных.
Необходимо отметить, что количество информации увеличивается не только в объеме, но и качественно. В результате появляется необходимость одновременной работы с ней нескольких экспертов. Кроме того, появляется возможность привлечения специализированных экспертов для выполнения сложных процедур анализа данных (Data mining Интеллектуальный анализ данных). Сегодня не только для формирования будущей стратегии, но и для выполнения повседневных задач все большее значение имеет прогнозная аналитика, которая для формирования верного вектора развития использует объективные, а не субъективные данные.
Помимо этого единая база данных упрощает формирования отчетности как отдельным подразделениям компании, так и всей компании в целом для подачи документов в государственные инстанции или их предоставления для ознакомления внешним экспертным комиссиям. Единая база позволяет в автоматическом режиме обновлять документацию, относящуюся к нормативно-справочной информации (НСИ). Дополнительно общая база данных позволяет оперировать информацией в своеобразной унифицированной форме, делая процедуры анализа информации более единообразными в рамках компании.
Еще одним плюсом от единого подхода к хранению информации является гораздо более простая процедура резервирования, снижение времени простоя после сбоя, обеспечение безопасности данных в плане распределения прав доступа, более прозрачная процедура миграции на новые версии программного и аппаратного обеспечения.
Рынок СУБД в России
Российские СУБД на сегодняшний день находятся в довольно тяжелом положении — разработки крупных компаний выдавливают из рынка российские системы. Однако, до сих пор есть несколько СУБД, которые продолжают оставаться на плаву за счёт внедрения в государственные структуры.
Классификация
В зависимости от архитектуры построения системы управления базами СУБД могут подразделяться на следующие типы:
Файловые системы
Представим себе, что имеется некоторый носитель информации определенной емкости, устройство для чтения-записи на этот носитель в режиме произвольного доступа и прикладные программы, которые используют конкретный носитель для ввода-вывода информации во внешнюю память. В этом случае, каждая прикладная программа должна знать где и в каком месте хранятся необходимые данные. Так как прикладных программ больше, чем носителей информации, то несколько прикладных программ могут использовать один накопитель. Что произойдет, если одной из прикладных программ потребуется дозаписать свои данные на диск? Может произойти наложение: ситуация в которой данные одной программы будут перезаписаны другой программой. Важным шагом в развитии информационных систем явился переход к использованию централизованных систем управления файлами. С точки зрения прикладной программы, файл – именованная область внешней памяти, в которую можно записывать данные, и из которой можно их считывать. Для того чтобы была возможность считать информацию из какой либо области внешней памяти необходимо знать имя этого сектора(имя файла), размер самой области и его физическое расположение. Сама система управления файлами выполняет следующие функции:
Рассмотрение особенностей реализации отдельных систем управления файлами выходит за рамки данной темы. На данном этапе достаточно знать, что прикладные программы видят файл как линейную последовательность записей и могут выполнить над ним ряд операций. Основные операции сфайлами в СУФ:
СУБД крупных ЭВМ
Данный этап развития связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и различных моделях фирмы Hewlett Packard. В таком случае информация хранилась во внешней памяти центральной ЭВМ. Пользователями баз данных были фактически задачи, запускаемые в основном в пакетном режиме. Интерактивный режим доступа обеспечивался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами (процессором, оперативной памятью, внешней памятью) и служили только устройствами ввода-вывода для центральной ЭВМ. Программы доступа к БД писались на различных языках программирования и запускались как обычные числовые программы. Особенности данного этапа:
Настольные СУБД
Компьютеры стали ближе и доступнее каждому пользователю. Исчез благоговейный страх рядовых пользователей перед непонятными и сложными языками программирования. Появилось множество программ, предназначенных для работы неподготовленных пользователей. Простыми и понятными стали операции копирования файлов и переноса информации с одного компьютера на другой, распечатка текстов, таблиц и других документов. Системные программисты были отодвинуты на второй план. Каждый пользователь мог себя почувствовать полным хозяином этого мощного и удобного устройства, позволяющего автоматизировать многие аспекты собственной деятельности. И, конечно, это сказалось и на работе с базами данных. Новоявленные СУБД позволяли хранить значительные объемы информации, они имели удобный интерфейс для заполнения, встроенные средства для генерации различных отчетов. Эти программы позволяли автоматизировать многие учетные функции, которые раньше велись вручную. Постоянное снижение цен на персональные компьютеры сделало такое ПО доступным не только для организаций и фирм, но и для отдельных пользователей.
Компьютеры стали инструментом для ведения документации и собственных учетных функций. Это все сыграло как положительную, так и отрицательную роль в области развития баз данных. Кажущаяся простота и доступность персональных компьютеров и их программного обеспечения породила множество дилетантов. Много было создано систем-однодневок, которые не отвечали законам развития и взаимосвязи реальных объектов. Однако доступность персональных компьютеров заставила пользователей из многих областей знаний, которые ранее не применяли вычислительную технику в своей деятельности, обратиться к ним. И спрос на развитые удобные программы обработки данных заставлял поставщиков программного обеспечения поставлять все новые системы, которые принято называть настольными СУБД. Значительная конкуренция среди поставщиков заставляла совершенствовать эти конфигурации, предлагая новые возможности, улучшая интерфейс и быстродействие систем, снижая их стоимость. Наличие на рынке большого числа СУБД, выполняющих сходные функции, потребовало разработки методов экспорта-импорта данных для этих систем и открытия форматов хранения данных. Но и в этот период появлялись любители, которые вопреки здравому смыслу разрабатывали собственные СУБД, используя стандартные языки программирования. Это был тупиковый вариант, потому что дальнейшее развитие показало, что перенести данные из нестандартных форматов в новые СУБД было гораздо труднее, а в некоторых случаях требовало таких трудозатрат, что легче было бы все разработать заново, но данные все равно надо было переносить на новую более перспективную СУБД. И это тоже было результатом недооценки тех функции, которые должна была выполнять СУБД. Особенности этого этапа следующие:
Продукты
Каталог СУБД-решений и проектов доступен на TAdviser.
История
Базы данных использовались в вычислительной технике с незапамятных времен. В первых компьютерах использовались два вида внешних устройств – магнитные ленты и магнитные барабаны. Емкость магнитных лент была достаточно велика. Устройства для чтения-записи магнитных лент обеспечивали последовательный доступ к данным. Для чтения информации, которая находилась в середине или конце магнитной ленты, необходимо было сначала прочитать весь предыдущий участок. Следствием этого являлось чрезвычайно низкая производительность операций ввода-вывода данных во внешнюю память. Магнитные барабаны давали возможность произвольного доступа, но имели ограниченный объем хранимой информации. Разумеется, говорить о какой-либо системе управления данными во внешней памяти, в тот момент не приходилось. Каждая прикладная программа, которой требовалось хранить данные во внешней памяти, сама определяла расположение каждого блока на магнитной ленте. Прикладная программа также брала на себя функции информационного обмена между оперативной памятью и устройствами внешней памяти с помощью программно-аппаратных средств низкого уровня.
Такой режим работы не позволяет или очень затрудняет поддержку на одном носителе нескольких архивов долговременно хранимой информации. Кроме того, каждой прикладной программе приходилось решать проблемы именования частей данных и структуризации во внешней памяти. История БД фактически началась с появлением магнитных дисков. Такие устройства внешней памяти обладали существенно большей емкостью, чем магнитная лента и барабаны, а также обеспечивали во много раз большую скорость доступа в режиме произвольной выборки. В отличие от современных систем управления, которые могут применяться для самых различных баз данных, подавляющее большинство ранее разработанных СУБД были тесно связаны с пользовательской базой для того, чтобы увеличить скорость работы, хоть и в ущерб гибкости. Первоначально СУБД применялись только в крупных организациях с мощной аппаратной поддержкой, необходимой для работы с большими объемами данных.
Фактически данный продукт представлял собой компиляцию утилит, которые использовались с системами System/360 на шаттлах Аполлон. Решение было разработано согласно коцпетам CODASYL, но при этом была применена строгая иерархия для структуризации данных. В свою очередь в варианте CODASYL за базис была взята сетевая СУБД. Оба варианта, меж тем, были приняты сообществом позднее как классические варианты организации работы СУБД, а сам Чарльз Бахман в 1973 году получил премию Тьюринга за работу Программист как навигатор. В 1970 году сотрудник компании IBM Эдгар Кодд, работавший в одном из отделений Сан Хосе (США), в котором занимались разработкой систем хранения, написал ряд статей, касающихся навигационных моделей СУБД. Заинтересовавшись вопросом он разработал и изложил несколько инновационных подходов касательно оптимальной организаци систем управления БД. Работа Кодда внесла значительный вклад в развитие СУБД и является действительным основоположником теории реляционных баз данных. Уже 1981 году Э.Ф.Кодд создал реляционную модель данных и применил к ней операции реляционной алгебры.