Понятие бд и субд, функции субд

Классификации СУБД

По модели данных

Примеры:

• Иерархические
• Сетевые
• Реляционные
• Объектно-ориентированные
• Объектно-реляционные

По степени распределённости

• Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)
• Распределённые СУБД (части СУБД могут размещаться не только на одном, но на двух и более компьютерах).

По способу доступа к БД

Файл-серверные

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

Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера.

Недостатки: потенциально высокая загрузка локальной сети; затруднённость или невозможность централизованного управления; затруднённость или невозможность обеспечения таких важных характеристик, как высокая надёжность, высокая доступность и высокая безопасность. Применяются чаще всего в локальных приложениях, которые используют функции управления БД; в системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками на БД.

На данный момент файл-серверная технология считается устаревшей, а её использование в крупных информационных системах — недостатком.

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

Клиент-серверные

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

Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу.

Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик, как высокая надёжность, высокая доступность и высокая безопасность.

Примеры: Oracle Database, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, , PostgreSQL, MySQL, Caché, ЛИНТЕР.

Встраиваемые

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

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

Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.

Мультимодельные СУБД на основе реляционной модели

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

Автору, однако, больше нравится реализация мультимодельности в Microsoft SQL Server, на примере которого поддержка РСУБД документной и графовой моделей и будет описана.

Документная модель в MS SQL Server

О том, как в MS SQL Server реализована поддержка документной модели, на Хабре уже было две отличных статьи, ограничусь кратким пересказом и комментарием:

• Работаем с JSON в SQL Server 2016
• SQL Server 2017 JSON

Способ поддержки документной модели в MS SQL Server достаточно типичен для реляционных СУБД: JSON-документы предлагается хранить в обычных текстовых полях. Поддержка документной модели заключается в предоставлении специальных операторов для разбора этого JSON:

• для извлечения скалярных значений атрибутов,
• для извлечения поддокументов.

Вторым аргументом обоих операторов является выражение в JSONPath-подобном синтаксисе.

Абстрактно можно сказать, что хранимые таким образом документы не являются в реляционной СУБД «сущностями первого класса», в отличие от кортежей. Конкретно в MS SQL Server в настоящее время отсутствуют индексы по полям JSON-документов, что делает затруднительными операции соединения таблиц по значениям этих полей и даже выборку документов по этим значениям. Впрочем, возможно создать по такому полю вычислимый столбец и индекс по нему.

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

Наконец, MS SQL Server позволяет решать задачу, обратную конструированию документа: можно разложить JSON по таблицам с помощью . Если документ не совсем плоский, потребуется использовать .

Графовая модель в MS SQL Server

Поддержка графовой (LPG) модели реализована в Microsoft SQL Server тоже вполне предсказуемо: предлагается использовать специальные таблицы для хранения узлов и для хранения ребер графа. Такие таблицы создаются с использованием выражений и соответственно.

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

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

Проиллюстрируем сказанное примером. Пусть графовые данные имеют схему как на приведенном рисунке. Тогда для создания соответствующей структуры в базе данных нужно выполнить следующие DDL-запросы:

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

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

Подводя итог описанию реализаций документной и графовой моделей в MS SQL Server, я бы отметил, что подобные реализации одной модели поверх другой не кажутся удачными в первую очередь с точки зрения языкового дизайна. Требуется расширять один язык другим, языки не вполне «ортогональны», правила сочетаемости могут быть довольно причудливы.

Виды баз данных

Существует огромное количество разновидностей баз данных, отличающихся по различным критериям. Например, в «Энциклопедии технологий баз данных», по материалам которой написан данный раздел, определяются свыше 50 видов БД.

Основные классификации приведены ниже.

Классификация по модели данных

Примеры:

• Иерархическая
• Объектная и объектно-ориентированная
• Объектно-реляционная
• Реляционная
• Сетевая
• Функциональная.

Классификация по среде постоянного хранения

• Во вторичной памяти, или традиционная (англ. conventional database): средой постоянного хранения является периферийная энергонезависимая память (вторичная память) — как правило жёсткий диск.В оперативную память СУБД помещает лишь кэш и данные для текущей обработки.
• В оперативной памяти (англ. in-memory database, memory-resident database, main memory database): все данные на стадии исполнения находятся в оперативной памяти.
• В третичной памяти (англ. tertiary database): средой постоянного хранения является отсоединяемое от сервера устройство массового хранения (третичная память), как правило на основе магнитных лент или оптических дисков.Во вторичной памяти сервера хранится лишь каталог данных третичной памяти, файловый кэш и данные для текущей обработки; загрузка же самих данных требует специальной процедуры.

Примеры:

• Географическая
• Историческая
• Научная
• Мультимедийная
• Клиентская.

Классификация по степени распределённости

• Централизованная, или сосредоточенная (англ. centralized database): БД, полностью поддерживаемая на одном компьютере.
• Распределённая БД (англ. distributed database) — составные части которой размещаются в различных узлах компьютерной сети в соответствии с каким-либо критерием.
  • Неоднородная (англ. heterogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами более одной СУБД.
  • Однородная (англ. homogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами одной и той же СУБД.
  • Фрагментированная, или секционированная (англ. partitioned database): методом распределения данных является фрагментирование (партиционирование, секционирование), вертикальное или горизонтальное.
  • Тиражированная (англ. replicated database): методом распределения данных является тиражирование (репликация).

Другие виды БД

• Пространственная (англ. spatial database): БД, в которой поддерживаются пространственные свойства сущностей предметной области. Такие БД широко используются в геоинформационных системах.
• Временная, или темпоральная (англ. temporal database): БД, в которой поддерживается какой-либо аспект времени, не считая времени, определяемого пользователем.
• Пространственно-временная (англ. spatial-temporal database) БД: БД, в которой одновременно поддерживается одно или более измерений в аспектах как пространства, так и времени.
• Циклическая (англ. round-robin database): БД, объём хранимых данных которой не меняется со временем, поскольку в процессе сохранения новых данных они заменяют более старые данные. Одни и те же ячейки для данных используются циклически.

База данных сайта — что это?

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

База данных (сокращённо БД) — это хранилище всей информации, расположенной на сайте

И совершенно неважно, к какому типу сайта принадлежит ресурс. Если он имеет больше одной страницы, БД у него гарантировано есть

Ещё одной вещью, которую нужно запомнить, является то, что БД состоит из таблиц, у которых есть набор полей. В них-то вся информация и расположена в виде кортежей (записей). Например, «Красная Феррари» будет кортежем в таблице «Модели», у которой есть поля «Производитель» и «Цвет». Таблица, в свою очередь, будет частью БД «Машины».

1. Сущность — это объект предметной области.

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

2. Атрибут сущности — это свойство объекта.

   В нашем примере атрибутами книги будут являться «ФИО автора», «количество экземпляров», «год выхода», «переплёт». В структуре БД они представлены полями таблиц.

3. Отношения — это логические связи между таблицами.

   Например, у книги есть автор. Данное отношение будет выражено одинаковыми полями в обоих таблицах.

   Структура таблиц будет зависеть от типа отношений, которые бывают:

   • «один-к-одному» — одной записи из первой таблицы соответствует один объект другой таблицы.

     Пример: издательство печатает произведения одного-единственного автора. Довольно часто такие таблицы объединяются;

   • «один-ко-многим» — записи из первой таблицы соответствует несколько записей из второй таблицы.

     Пример: у автора может быть много книг, у книги может быть много авторов. как и в предыдущем случае, каждому участнику отношений соответствует отдельная таблица;

   • «многие-ко-многим» — множеству записей из первой таблицы может соответствовать множество записей из второй таблицы.

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

По поводу полей таблиц следует отметить, что у каждого поля есть:

• имя — наименование поля;
• описание — необязательно для заполнения, больше необходимо самому пользователю, чтобы вспомнить, какие данные здесь хранятся;
• тип данных — тип вводимых данных (текстовый, числовой, временной и т.д.), от которого будут зависеть операции и набор функций, которыми можно обрабатывать содержимое такого поля.

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

Для чего нужны

Вот основ­ные зада­чи БД на при­ме­ре гардеробной:

• Сохра­нить наши дан­ные по запро­су — что­бы вы мог­ли открыть дверь, пове­сить курт­ку, закрыть дверь и боль­ше не думать ни о курт­ке, ни о гардеробной.
• Изме­нить наши дан­ные по запро­су — что­бы мож­но было лег­ко извлечь из гар­де­роб­ной все дыря­вые нос­ки и поло­жить на их место целые.
• Най­ти эти дан­ные по запро­су — что­бы быст­ро най­ти при­лич­ный пиджак или пар­ный носок.
• Не дать про­чи­тать эти дан­ные тем, кому не сле­ду­ет, а кому надо — дать. Напри­мер, млад­ший брат может смот­реть на ваши крос­сов­ки, но не может их брать. А девуш­ка (или парень) может поло­жить свои вещи, но толь­ко на опре­де­лён­ную полку.
• Под­дер­жи­вать поря­док и не дать захла­мить­ся — если вам было лень и вы про­сто кину­ли тол­стов­ку куда попа­ло, что­бы гар­де­роб­ная либо сама нашла, куда эту тол­стов­ку пра­виль­но поло­жить, либо ска­за­ла: «Э БРАТ ЗАЧЕМ ЗАХЛАМЛЯЕШЬ ПОЛОЖИ НОРМАЛЬНО ДАВАЙ»
• Мас­шта­би­ро­вать­ся — что­бы вы мог­ли про­сто вешать в гар­де­роб­ную вещи и не думать об объ­ё­ме полок.
• Не поте­рять дан­ные — если квар­ти­ра будет гореть, при­лич­ная гар­де­роб­ная не долж­на даже нагреть­ся. Или, если она всё-таки горит, что­бы где-то в защи­щён­ном под­зем­ном гара­же была точ­ная копия этой гар­де­роб­ной со все­ми акту­аль­ны­ми вещами.

Требования к проектированию БД

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

Требования обычно следующие:
1. База данных должна быть относительно простой в плане обработки информации.
2. Она должна быть максимально компактной и неизбыточной настолько, насколько это возможно без ущерба для функциональности.

Возможны и другие требования, причём нередко они противоречат друг другу

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

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

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

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

Список использованной литературы

1. Кузин А.В., Левонисова С.В. Базы данных. Учебное пособие. – М.: Академия, 2017.
2. Мельников В.П. Информационные технологии. Учебник. – М.: Академия, 2015.
3. Острейковский В.А. Информатика: Учебник для вузов. – М.: Высшая школа, 2014.
4. Симонович С.В. Информатика. Базовый курс. – СПб.: Питер, 2011.
5. Советов Б.Я., Целиховский В.В. Информационные технологии: Учебник для вузов. – М.: Высшая школа, 2015.
6. Степанов А.Н. Информатика. Базовый курс для студентов гуманитарных специальностей высших учебных заведений. – СПб.: Питер, 2017.
7. Уткин В.Б., Балдин К.В. Информационные технологии управления. Учебник. – М.: Академия, 2013.

Понятие БД и классификация БД

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

Безопасность данных также приобретает все большее значение, в электронных БД хранятся и шифруются пароли, личные данные и даже электронные валюты.

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

В зависимости от изменчивости базы данных ее тип относят по классификации БД к статическому или динамическому.

Функции статических БД:

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

Функции динамических БД:

1. Они обладают понятием самоуправления.
2. Могут быть связаны с динамическими сетями.
3. Эта структурная ассоциация позволяет хранить и обновлять информацию базы данных.
4. Использует HTML в качестве языка связи между сетью и динамической БД.
5. Наиболее используемые языки для создания динамических сетей, связанных с BBDD: Perl, CGI, PHP, JSP и ASP.

Основными СУБД, которые работают с динамическими веб-страницами, являются PostgresQL, MySQL, Oracle и Microsoft SQL.

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

• библиографические;
• документальные;
• специализированные;
• справочники.

Функциональные возможности библиографических БД:

1. Связаны со старыми записями, которые содержат информацию о местонахождении книги или документа.
2. Не содержат полный текст, только ссылку.
3. Благодаря таким форматам, как PDF, позволяет получать доступ к оригинальным статьям, на которые есть ссылки.
4. С развитием технологий включаются ссылки из других СМИ.

Особенности специализированных БД:

1. Содержат точную информацию и ориентированы на конкретную тему.
2. Используются в академической и научной среде.
3. Для некоторых случаев не рассматриваются как правильные BBDD: например, телефонный справочник, список контактов компании или международной компании.

Примеры базы данных

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

1. телефонный справочник;
2. учет сотрудников организации;
3. учет преподавателей и их расписания в вузах;
4. регистратура в больнице или другом учреждении.

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

Если все-таки будут, приглашаю спуститься в комментарии и подискутировать на эту тему с другими читателями блога KtoNaNovenkogo.ru.

Для закрепления знаний предлагаю посмотреть видео по теме:

Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru

В чём преимущества

Базы дан­ных и их систе­мы управ­ле­ния зато­че­ны на рабо­ту с боль­шим объ­ё­мом дан­ных и от лица боль­шо­го чис­ла поль­зо­ва­те­лей. Сей­час вы поймёте.

Ско­рость — ещё одно пре­иму­ще­ство базы дан­ных. База дан­ных устро­е­на так, что она лег­ко и быст­ро нахо­дит, запи­сы­ва­ет, пере­пи­сы­ва­ет и сно­ва нахо­дит дан­ные. Всё пото­му, что СУБД все­гда зна­ет, что где лежит и по како­му кри­те­рию искать. Там не будет слу­чай­ных дан­ных в слу­чай­ном месте.

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

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

• Свя­зы­вать одну еди­ни­цу дан­ных с мно­же­ством дру­гих. Напри­мер, если один чело­век совер­шил мно­го зака­зов со мно­же­ством това­ров внут­ри каж­до­го, база дан­ных спо­соб­на хра­нить и обра­ба­ты­вать такие связи.
• База может хра­нить дере­во дан­ных — вро­де того, о кото­ром мы писа­ли недав­но. Попро­буй в реаль­ной жиз­ни похра­нить дерево!
• В базах могут жить ссыл­ки на дру­гие фраг­мен­ты и отде­лы базы.

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

Как хранится информация в БД

В основе всей структуры хранения лежат три понятия:

• База данных;
• Таблица;
• Запись.

База данных

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

Таблица

По отношению к базе данных таблица является вложенным объеком. То есть одна БД может содержать в себе множество таблиц.
Аналогией из реального мира может быть шкаф (база данных) внутри которого лежит множество коробок (таблиц).
Таблицы нужны для хранения данных одного типа, например, списка городов, пользователей сайта, или библиотечного каталога.
Таблицу можно представить как обычный лист в Excel-таблице, то есть совокупность строк и столбцов.
Наверняка каждый хоть раз имел дело с электронными таблицами (MS Excel).
Заполняя такую таблицу, пользователь определяет столбцы, у каждого из которых есть заголовок. В строках хранится информация.
В БД точно также: создавая новую таблицу, необходимо описать, из каких столбцов она состоит, и дать им имена.

Запись

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

Соберем всё вместе, чтобы понять, как будет выглядеть ведение дневника погоды при участии базы данных.

1. Создадим для сайта новую БД и дадим ей название «weather_diary».
2. Создадим в БД новую таблицу с именем «weather_log» и определим там следующие столбцы:
   • Город (тип: текст);
   • День (тип: дата);
   • Температура (тип: число);
   • Облачность (тип: число; от 0 (нет облачности) до 4 (полная облачность));
   • Были ли осадки (тип: истина или ложь);
   • Комментарий (тип: текст).
3. При сохранении формы будем добавлять в таблицу weather_log новую запись, и заполнять в ней все поля информацией из полей формы.

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

Реляционная база данных

Английское слово „relation“ можно перевести как связь, отношение.
А определение «реляционные базы данных» означает, что таблицы в этой БД могут вступать в отношения и находиться в связи между собой.
Что это за связи?
Например, одна таблица может ссылаться на другую таблицу. Это часто требуется, чтобы сократить объём и избежать дублирования информации.
В сценарии с дневником погоды пользователь вводит название своего города. Это название сохраняется вместе с погодными данными.
Но можно поступить иначе:

1. Создать новую таблицу с именем „cities“.
2. Все города в России известны, поэтому их все можно добавить в одну таблицу.
3. Переделать форму, изменив поле ввода города с текстового на поле типа «select», чтобы пользователь не вписывал город, а выбирал его из списка.
4. При сохранении погодной записи, в поле для города поставить ссылку на соответствующую запись из таблицы городов.

Так мы решим сразу две задачи:

• Сократим объём хранимой информации, так как погодные записи больше не будут содержать название города;
• Избежим дублирования: все пользователи будут выбирать один из заранее определённых городов, что исключит опечатки.

Связи между таблицами в БД бывают разных видов.
В примере выше использовалась связь типа «один-ко-многим», так как одному городу может соответствовать множество погодных записей, но не наоборот!
Бывают связи и других типов: «один-к-одному» и «многие-ко-многим», но они используются значительно реже.

Области применения

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

Области применения СУБД:

1. Банковское дело — для информации о клиентах, счетов и займов, а также банковских операций.
2. Авиакомпании — для бронирования и информации о расписании. Авиакомпании были одними из первых, кто использовал базы данных в географически распределенном порядке: терминалы, расположенные по всему миру, обращались к центральной системе баз данных через телефонные линии и другие сети передачи данных.
3. Университеты — для информации о студентах, регистрации курсов и оценок.
4. Операции с кредитными картами — для покупок по кредитным картам и формирования ежемесячных выписок.
5. Телекоммуникации — для ведения записей о совершенных вызовах, составления ежемесячных счетов, поддержания баланса на телефонных карточках с предоплатой и хранения информации о сетях связи.
6. Финансы — для хранения информации о запасах, продажах и покупках финансовых инструментов, таких, как акции и облигации.
7. Продажи — информация о клиенте, продукте и покупке.
8. Производство — для управления цепочкой поставок и для отслеживания производства товаров на фабриках, запасов товаров на складах, в магазинах и заказов на товары.
9. Человеческие ресурсы — для получения информации о сотрудниках, заработной плате, налогах на заработную плату и льготах, а также для получения зарплат.

Основные понятия СУБД

Определение 1

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

Определение 2

Реляционная база данных – это множество таблиц, взаимосвязанных между собой, причем в каждой из них содержится информация об объектах определенного типа. В каждой строке таблицы содержатся данные об одном объекте (например, человеке, средстве передвижения), а в столбцах таблицы содержатся разные характеристики этих объектов, которые называются атрибутами (например, имена и адреса людей).

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

При работе с данными используют специальные системы, которые называются системами управления базами данных (СУБД).

Определение 3

Система управления базами данных (СУБД) является совокупностью программных и лингвистических средств общего или специального назначения, которые обеспечивают управление созданием и использованием баз данных

К основным функциям СУБД относятся определение данных (описание структуры БД), их обработка и управление.

Замечание 1

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

Рассмотрим отношение между преподавателями и их курсами лекций, отношение типа многие-ко-многим, поскольку 1 преподаватель может вести несколько курсов, в тоже время 1 курс могут вести несколько преподавателей.

И последний тип межтабличных связей — отношение один-к-одному. Этот тип отношений встречается намного реже. Может встречаться лишь в 2 случаях:

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

Любой СУБД могут выполняться 4 наиболее простые операции с данными:

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

Для выполнения указанных операций используют механизм запросов. Результат выполнения запросов бывает представлен отобранным по определенным критериям множеством записей или изменениями в таблицах. Запрос к базе формируется на специально созданном для этих целей языке, называемом языком структурированных запросов (SQL — Structured Query Language).

Определение 4

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

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

Главное о базах данных

• Чаще все­го базы дан­ных напо­ми­на­ют таб­ли­цы: в них одно­му пара­мет­ру соот­вет­ству­ет один набор дан­ных. Напри­мер, один кли­ент — одно имя, один теле­фон, один адрес.
• Такие «таб­лич­ные» базы дан­ных назы­ва­ют­ся реляционными.
• Что­бы стро­ить слож­ные свя­зи, раз­ные таб­ли­цы в реля­ци­он­ных базах мож­но свя­зы­вать меж­ду собой: ста­вить ссылки.
• Реля­ци­он­ная база — не един­ствен­ный спо­соб хра­не­ния дан­ных. Есть ситу­а­ции, когда нам нуж­на боль­шая гиб­кость в хранении.
• Быва­ют сете­вые базы дан­ных: когда нуж­но хра­нить мно­го свя­зей меж­ду мно­же­ством объ­ек­тов. Напри­мер, ката­лог филь­мов: в одном филь­ме может участ­во­вать мно­го чело­век, а каж­дый из них может участ­во­вать во мно­же­стве фильмов.
• Быва­ют иерар­хи­че­ские базы, или «дере­вья». При­мер — наша фай­ло­вая система.
• Какую выбрать базу — зави­сит от зада­чи. Одна база не луч­ше дру­гой, но они могут быть более или менее под­хо­дя­щи­ми для опре­де­лён­ных задач.

Текст и иллю­стра­ции:Миша Поля­нин
Редак­тор:Мак­сим Ильяхов
Кор­рек­тор:Ира Михе­е­ва
Иллю­стра­тор:Даня Бер­ков­ский
Вёрст­ка:Маша Дро­но­ва
Достав­ка:Олег Веш­кур­цев
Что-то дела­ет рука­ми:Паша Федо­ров
Во сла­ву:Прак­ти­ку­ма

Заключение

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

Рынок систем управления базами данных продолжает развиваться и все больше склоняется к использованию NoSQL – решений. Естественно, на «классическом» SQL реализовано существенное количество программных систем разной сложности, и за ним стоят такие гиганты рынка как Microsoft и ORACLE. Однако, с большой долей уверенности можно говорить о том, что NoSQL в ближайшее время достаточно сильно потеснят лидеров в разработке сложных информационных систем.