Что такое база данных какими свойствами она должна обладать

Свойства полей базы данных

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

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

• Тип поля — определяет тип данных, которые могут содержаться в данном поле.

• Размер поля — определяет предельную длину (в символах) данных, которые могут размещаться в данном поле.

• Формат поля — определяет способ форматирования данных в ячейках, принадлежащих полю.

• Маска ввода — определяет форму, в которой вводятся данные в поле (средство автоматизации ввода данных).

• Подпись — определяет заголовок столбца таблицы для данного поля (если подпись не указана, то в качестве заголовка столбца используется свойство Имя поля).

• Значение по умолчанию — то значение, которое вводится в ячейки поля автоматически (средство автоматизации ввода данных).

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

• Сообщение об ошибке — текстовое сообщение, которое выдается автоматически при попытке ввода в поле ошибочных данных (проверка ошибочности выполняется автоматически, если задано свойство Условие на значение).

• Обязательное поле — свойство, определяющее обязательность заполнения данного поля при наполнении базы;

• Пустые строки — свойство, разрешающее ввод пустых строковых данных (от свойства Обязательное поле отличается тем, что относится не ко всем типам данных, а лишь к некоторым, например к текстовым).

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

Здесь мы должны обратить особое внимание читателя на то, что поскольку в разных полях могут содержаться данные разного типа, то и свойства у полей могут различаться в зависимости от типа данных. Так, например, список вышеуказанных свойств полей относится в основном к полям текстового типа. Поля других типов могут иметь или не иметь эти свойства, но могут добавлять к ним и свои. Например для данных, представляющих действительные числа, важным свойством является количество знаков после десятичной запятой. С другой стороны, для полей, используемых для хранения рисунков, звукозаписей, видеоклипов и других объектов OLE, большинство вышеуказанных свойств не имеют смысла.

С основными типами данных мы уже знакомы. Так, например, при изучении электронных таблиц Microsoft Excel мы видели, что они работают с тремя типами данных: текстами, числами и формулами. Таблицы баз данных, как правило, допускают работу с гораздо большим количеством разных типов данных. Так, например, базы данных Microsoft Access работают со следующими типами данных (рис. 13.2).

Рис. 13.2. Таблица с полями некоторых типов

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

Поле Мемо — специальный тип данных для хранения больших объемов текста (до 65 535 символов). Физически текст не хранится в поле. Он хранится в другом месте базы данных, а в поле хранится указатель на него, но для пользователя такое разделение заметно не всегда.

Числовой — тип данных для хранения действительных чисел.

Дата/время — тип данных для хранения календарных дат и текущего времени.

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

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

• Логический — тип для хранения логических данных (могут принимать только два значения, например Да или Нет).

• Поле объекта OLE — специальный тип данных, предназначенный для хранения объектов OLE, например мультимедийных. Реально, конечно, такие объекты в таблице не хранятся. Как и в случае полей MEMO, они хранятся в другом месте внутренней структуры файла базы данных, а в таблице хранятся только указатели на них (иначе работа с таблицами была бы чрезвычайно замедленной).

• Гиперссылка — специальное поле для хранения адресов URL Web-объектов Интернета. При щелчке на ссылке автоматически происходит запуск броузера и воспроизведение объекта в его окне.

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

Объекты базы данных

Мы уже упомянули о том, что кроме таблиц база данных может содержать и другие типы объектов. Привести полную классификацию возможных объектов баз данных затруднительно, поскольку каждая система управления базами данных может реализовать свои типы объектов. Однако основные типы объектов мы можем рассмотреть на примере СУБД Microsoft Access. В версии Microsoft Access 2000 эта СУБД позволяет создавать и использовать объекты семи различных типов.

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

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

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

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

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

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

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

Рис. 13.3. Два запроса, сформированные на основе одной таблицы

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

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

Рис. 13.4. Форма для оформленного вывода данных

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

Рис. 13.5. Пример простейшего отчета

Страницы.Это специальные объекты баз данных, реализованные в последней версии СУБД Microsoft Access (Access 2000). Правда, более корректно их называть страницами доступа к данным. Физически это особый объект, выполненный в коде HTML, размещаемый на Web-странице и передаваемый клиенту вместе с ней. Сам по себе этот объект не является базой данных, но содержит компоненты, через которые осуществляется связь переданной Web-страницы с базой данных, остающейся на сервере. Пользуясь этими компонентами, посетитель Web-узла может просматривать записи базы в полях страницы доступа (рис. 13.6). Таким образом, страницы доступа к данным осуществляют интерфейс между клиентом, сервером и базой данных, размещенной на сервере. Эта база данных не обязательно должна быть базой данных Microsoft Access. Страницы доступа, созданные средствами Microsoft Access, позволяют работать также с базами данных Microsoft SQL Server.

Рис. 13.6. Пример простейшей страницы доступа

Макросы и модули.Эти категории объектов предназначены как для автоматизации повторяющихся операций при работе с системой управления базами данных, так и для создания новых функций путем программирования. В СУБД Microsoft Access макросы состоят из последовательности внутренних команд СУБД и являются одним из средств автоматизации работы с базой. Модули создаются средствами внешнего языка программирования, в данном случае языка Visual Basic for Applications. Это одно из средств, с помощью которых разработчик базы может заложить в нее нестандартные функциональные возможности, удовлетворить специфические требования заказчика, повысить быстродействие системы управления, а также уровень ее защищенности.

Статьи к прочтению:

• Свойства полей, их назначение (ms access).
• Связь компьютера с периферийными устройствами

Свойства функции

Похожие статьи:

• Раскроем ведущие объекты базы данных. Таблицы. Это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру…
• Свойства полей, их назначение (ms access). Для каждого из типов полей существует свой набор свойств. 1)Размер поля. Значение этого свойства указывает максимальный размер данных, которые могут…

7 основных типов баз данных

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

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

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

Примеры — MySQL, Oracle DB, PostgreSQL. Это самый популярный тип БД, в которых информация хранится в виде таблиц. В строках находится описание каждого отдельного свойства объекта, а столбцы нужны для извлечения определённых свойств из строки. Таблицы могут быть взаимосвязаны.

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

В реляционных БД есть поддержка SQL, а также индексация, которая позволяет быстрее находить нужные данные. Особый плюс таких баз — нормализация данных: они делятся на разные таблицы, поэтому исключены повторяющиеся или пустые ячейки. Транзакции реляционных БД соответствуют ACID — набору свойств, который гарантирует их надёжную обработку. Из минусов баз можно отметить относительно низкую скорость доступа к данным, плохую поддержку неструктурированных данных, сложность масштабирования и образование большого количества таблиц, из-за чего бывает трудно понять структуру данных.

Резидентные базы данных

Примеры — Redis, Apache Ignite, Tarantool. Сведения хранятся в оперативной памяти. Данные обрабатываются быстро, поэтому резидентные БД популярны там, где нужно обеспечить максимально короткое время отклика. Они помогают управлять телекоммуникационным оборудованием, проводить торги в онлайн-режиме или Real-Time обслуживание. Базы in-memory поддерживают и быстрое написание, и быстрое чтение. В основном они работают с записями «ключ-значение», но также могут работать со столбцами.

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

Поисковые базы данных

Пример — Elastic. Этот тип БД нужен для получения сведений через фильтр. Искать можно по любому введённому значению, в том числе по отдельным словам. Можно пользоваться полнотекстовым поиском. Поисковые базы данных хорошо масштабируются и удобны для хранения журналов, объёмных текстовых значений.

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

Базы данных с широкими столбцами

Примеры — Cassandra, Google BigTable, HBase. БД с широкими столбцами могут запрашивать большие объёмы данных быстрее, чем обычные реляционные. Сведения хранятся в виде записей «‎ключ-значение»‎ на жёстком диске или твёрдотельном накопителе. Базы данных с широкими столбцами позволяют выполнять быструю запись построчно и быстрое чтение по ключу.

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

Столбчатые базы данных

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

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

Документоориентированные базы данных

Примеры — CouchDB, Couchbase, MongoDB. Если в реляционных БД для извлечения данных нужно объединять таблицы, то в этих базах отлично хранится несвязанная информация в больших объёмах. Они поддерживают JSON. Для любого ключа можно создать сложное значение и сразу включить всю структуру данных в одну запись. Выборка по запросу может содержать части множества документов без их полной загрузки в оперативную память.

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

Графовые базы данных

Примеры — OrientDB, Neo4j. Данные хранятся в виде графов, то есть моделей с узлами и связями. Они достаточно гибкие, с логичной структурой. Узлы служат для хранения сущностей данных, а рёбра — для хранения взаимосвязей между сущностями, которыми можно управлять.

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

Определяем базу данных под свои задачи

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

Отталкиваться нужно от следующих факторов:

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

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

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

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

Что такое база данных и зачем она?

Компании часто собирают информацию о своих клиентах, сотрудниках, операциях, финансах и т. д. Потом эту информацию можно выгодно использовать. Например, можно ее проанализировать и понять, какими способами можно увеличить прибыль. Можно на ее основе построить хитрые MLмодели, которые помогут улучшить продукт. Или, в конце концов, эту информацию можно просто перепродать другим компаниям.

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

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

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

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

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

Типы баз данных

Существует много разных типов баз данных. Наиболее популярные типы:

• Реляционные базы данных
• Key-value базы данных
• Документно-ориентированные базы данных
• Графовые базы данных
• Колоночные базы данных

Далее я расскажу о каждом из этих типов. Однако, начну я реляционных баз данных и больше всего буду рассказывать о них, потому что именно этим типом баз данных чаще всего пользуются аналитики данных и data scientist-ы.

Реляционные базы данных (MySQL, PostgreSQL, Oracle DB)

Реляционная база данных – это база данных, которая состоит из таблиц. У реляционной базы данных 2 очень важные характеристики:

• Данные распределены по смыслу по таблицам
• Между таблицами есть отношения

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

• Таблица с заказами
• Таблица с клиентами
• Таблица с курьерами
• Таблица с ресторанами

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

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

Primary key – это столбец (или группа столбцов) таблицы, который содержит уникальные значения для каждой строки. На примере выше primary key каждой таблицы я выделила зеленым цветом. То есть, например, в таблице с заказами каждая строка будет описывать отдельный заказ. Не будет 2 строк, которые описывают один и тот же заказ, потому ID заказа будет разный для каждой строки.

Foreign key – это столбец в таблице, который содержит primary key другой таблицы. На рисунке foreign key отмечены желтым. То есть, таблица с заказами содержит ID клиента, который является primary key в таблице с клиентами, но в таблице с заказами он будет foreign key.

Primary key и foreign key помогают не только связывать между собой таблицы реляционной базы данных отношениями. Они еще помогают следить за целостностью и правильностью данных в базе. Например, если мы ошибемся в ID клиента, добавляя новый заказ в таблицу с заказами, то база выдаст ошибку, так как не найдет соответствующий ID клиента в таблице с клиентами.

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

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

Одним из наиболее популярных методов ускорения работы запросов к реляционным базам данных является индексирование таблиц. Индекс – это определенный столбец в таблице, по которому осуществляется поиск.

Приведу пример работы индекса. Например, мы хотим найти все заказы клиента 007 из ресторана 1. Тогда, если у нас в таблице с заказами нет индекса, то мы будем перебирать все заказы пока не найдем нужные. Если же у нас есть индекс в таблице с заказами, то ситуация будет иной. Допустим, что индексом является столбец ID ресторана. Тогда наши данные в таблице с заказами будут сгруппированы по ID ресторана. И тогда при поиске заказов клиента 007 из ресторана 1, мы не будем перебирать всю таблицу с заказами, а найдем группу заказов из ресторана 1 и будем искать необходимые данные внутри этой группы.

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

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

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

Какие еще есть типы баз данных?

Прочие типы баз данных, которые не реляционные, часто называются noSQL базы данных. Обсудим наиболее популярные типы нереляционных баз данных.

Key-value базы данных (пример — Redis)

Название говорит о том, какие данные удобно хранить в Key-value базе – в такой базе хранят данные, которые удобно представить в виде пары ключ-значение. Основное преимущество таких баз – это очень быстрый поиск значения по ключу. При этом значение может содержать какие угодно типы данных.

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

Документно-ориентированные (пример — Mongo DB)

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

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

Графовые базы данных (пример — Orient DB)

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

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

Колоночные (столбцовые) базы данных (примеры — Cassandra, Clickhouse)

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

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

Ну и напоследок

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

• база данных
• реляционная база данных
• sql
• аналитика данных

Учебное пособие для студентов по дисциплине «Информатика» Модуль 3

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

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

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

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

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

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

Пример. Рассмотрим базу данных «Деканат», состоящую из трех таблиц: СТУДЕНТ, СЕССИЯ, СТИПЕНДИЯ, имеющих показанную ниже структуру.

Номер личного дела

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

Номер личного дела

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

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

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

Рис. 6. Пример реляционной структуры данных.

Таблицы СТУДЕНТ и СЕССИЯ имеют совпадающие первичные ключи (Номер личного дела), что дает возможность легко организовать связь между ними. Таблица СЕССИЯ имеет первичный ключ Номер личного дела и содержит внешний ключ Результат, который обеспечивает ее связь с таблицей СТИПЕНДИЯ.

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

Различают три типа связей (отношений) между таблицами реляционной базы данных:

• отношение «один-к-одному» (1 — 1)
• отношение «один-ко-многим» (1 — М)
• отношение «многие-ко-многим» (М — М)

Говорят, что таблицы А и В находятся в отношении «один-к-одному», если каждая запись в таблице А может иметь не более одной связанной с ней записи в таблице В и наоборот, каждая запись в таблице В может иметь не более одной связанной с ней записи в таблице А.

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

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

Рассмотренные ранее таблицы СТУДЕНТ и СЕССИЯ находятся в отношении «один-к-одному» (иначе говоря, между таблицами установлена связь типа «один-к-одному») (рис. 7).

Рис. 7. Пример таблиц, находящихся в отношении «один-к-одному».

Говорят, что таблицы А и В находятся в отношении «один-ко-многим», если каждая запись в таблице А может быть связана с несколькими записями таблицы В, но каждая запись в таблице В не может быть связана более чем с одной записью таблицы А. Таблица А в этом случае называется главной таблицей, а таблица В – подчиненной.

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

Например, рассмотренные ранее таблицы СТИПЕНДИЯ и СЕССИЯ находятся в отношении «один-ко-многим» (рис. 8). При этом на стороне «один» находится таблица СТИПЕНДИЯ, а на стороне «многие» – таблица СЕССИЯ. Связь устанавливается по полю Результат. Каждая запись таблицы СТИПЕНДИЯ может иметь много связанных с ней записей в таблице СЕССИЯ, иначе говоря, в таблице СЕССИЯ может быть много строк с заданным значением в поле Результат (например, со значением 1). В то же время, если взять любую строку в таблице СЕССИЯ, то для нее найдется не более одной строки в таблице СТИПЕНДИЯ с таким же значением в поле Результат.

Рис. 8. Пример таблиц, находящихся в отношении «один-ко-многим».

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

Такая связь всегда реализуется с помощью третьей (связующей) таблицы. Примером могут служить таблицы Читатели и Книги (рис. 9). Связь между ними организуется посредствам таблицы Абонемент.

Рис. 9. Пример таблиц, находящихся в отношении «многие-ко-многим».

Каждой записи в таблице Читатели могут соответствовать несколько записей в таблице Книги, и наоборот, каждая запись таблицы Книги может иметь более одной соответствующей ей записи в таблице Читатели. Соответствие устанавливается с помощью таблицы абонемент. При этом между таблицами ЧИТАТЕЛИ и АБОНЕМЕНТ установлено отношение «один-ко-многим», в котором таблица ЧИТАТЕЛИ является главной, а таблица АБОНЕМЕНТ – подчиненной. Аналогично между таблицами КНИГИ и АБОНЕМЕНТ установлено отношение «один-ко-многим», в которой таблица КНИГИ является главной.