на чем лучше писать базу данных

Своя СУБД за 3 недели. Нужно всего лишь каждый день немного времени…

Своя СУБД за 3 недели. Нужно всего-лишь каждый день немного времени уделять архитектуре; и всё остальное время вкалывать на результат, печатая и перепечатывая сотни строк кода.

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

Постановка задачи

Согласно ТЗ, требовалось создать СУБД с нуля на Vanilla Python 3.6 (без сторонних библиотек). Конечный продукт должен обладать следующими свойствами:

Подход к проектированию

Разработать СУБД с нуля казалось нетривиальной задачей (как ни странно, так оно и оказалось). Поэтому мы — ecat3 и @ratijas — подошли к этому делу научно. В команде нас только двое (не считая себя и мою персону), а значит распиливать задачи и координировать их выполнение в разы легче, чем, собственно, их выполнять. По окончании распила вышло следующе:

Задача	Исполнитель(-и)
Парсер + AST + REPL	ratijas, написавший не один калькулятор на всяких lex/yacc
Структура файла базы	ecat3, съевший собаку на файловых системах
Движок (низкоуровневые операции над базой)	ecat3
Интерфейс (высокоуровневая склейка)	Вместе

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

С формальной частью закончили, перейдем к практической. СУБД должна быть современной и актуальной. В современном Иннополисе актуальным является месседжер Телеграм, чат-боты и общение в группах с помощью «/слештегов» (это как #хештеги, только начинаются со /слеша). Поэтому язык запросов, близко напоминающий SQL, мало того что не чувствителен к регистру, так ещё и не чувствителен к /слешу непосредственно перед любым идентификатором: ‘SELECT’ и ‘/select’ это абсолютно одно и то же. Кроме того, подобно всякому студенту университета, каждая команда (statement) языка должна завершаться ‘/drop’. (Конечно же, тоже независимо от регистра. Кого вообще в такой ситуации волнует какой-то там регистр?)

Так родилась идея названия: dropSQL. Собственно /drop‘ом называется отчисление студента из университета; по некоторым причинам, это слово получило широкое распространение у нас в Иннополисе. (Ещё один местный феномен: аутизм, или, более корректно, /autism. Но мы приберегли его на особый случай.)

Первым делом разложили грамматику dropSQL на BNF (и зря — левые рекурсии не подходят нисходящим парсерам).

Работаем на результат! Никаких исключений!

После нескольких месяцев с Rust в качестве основного языка, крайне не хотелось снова погрязнуть в обработке исключений. Очевидным аргументом против исключений является то, что разбрасываться ими дорого, а ловить — громоздко. Ситуация ухудшается тем, что Python даже в версии 3.6 с Type Annotations, в отличие от той же Java, не позволяет указать типы исключений, которые могут вылететь из метода. Иначе говоря: глядя на сигнатуру метода, должно стать ясно, чего от него ожидать. Так почему бы не объеденить эти типы под одной крышей, которая называется «enum Error»? А над этим создать ещё одну «крышу» под названием Result; о нём пойдёт речь чуть ниже. Конечно, в стандартной библиотеке есть места, которые могут «взорваться»; но такие вызовы в нашем коде надежно обложены try’ями со всех сторон, которые сводят любое исключение к возврату ошибки, минимизируя возникновение внештатных ситуаций во время исполнения.

Итак, было решено навелосипедить алгебраический тип результата (привет, Rust). В питоне с алгебраическими типами всё плохо; а модуль стандартной библиотеки enum больше напоминает чистую сишечку.

В худших традициях ООП, используем наследование для определения конструкторов результата: Ok и Err. И не забываем про статическую типизацию (Ну мааам, у меня уже третья версия! Можно у меня будет наконец статическая типизация в Python, ну пожаалуйста?):

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

И сразу пример использования:

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

Парсер, IResult, Error::, REPL, 9600 бод и все-все-все

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

Один из первых вопросов, требовавших ответа: как быть с ошибками? Как быть — выше уже разобрались. Но что вообще представляет собой ошибка? Например, после «/create table» может находиться «if not exists», а может и не находиться — ошибка ли это? Если да, то какого рода? где должна быть обработана? («Поставьте на паузу», и предложите свои варианты в комментариях.)

Первая версия парсера различала два вида ошибок: Expected (ожидали одно, а получили что-то другое) и EOF (конец файла) как подкласс предыдущего. Всё бы ничего, пока дело не дошло до REPL. Такой парсер не различает между частиным вводом (началом команды) и отсутствием чего-либо (EOF, если так можно сказать про интерактивный ввод с терминала). Только неделю спустя, методом проб и ошибок удалось найти схему, удовлетворяющую нашей доменной области.

Схема состоит в том, что всё есть поток, а парсер — лишь скромный метод next() у потока. А также в том, что класс ошибки должен быть переписан на алгебраический (подобно Result), и вместо EOF введены варианты Empty и Incomplete.

IErr(Empty()) IErr(Empty()) Начало чего-то большего (нет закрывающей кавычки) IErr(Incomplete()) IErr(Incomplete()) Ты втираешь мне какую-то дичь IErr(Syntax(. )) IErr(Syntax(expected=’token’, got=’#’))

А самое приятное, что поток можно «собрать» в один большой список всех IOk(элементов), что выдает next() — до первой IErr(), разумеется. При чем список вернется лишь когда IErr содержала Empty; в противном случае, ошибка пробросится выше. Эта конструкция позволяет легко и элегантно построить REPL.

Characters

Этот поток проходит по символам строки. Единственный тип ошибки: Empty в конце строки.

Tokens

Поток токенов. Его второе имя — Лексер. Тут встречаются и ошибки, и строки без закрывающих кавычек, и всякое…

Каждый тип токенов, включая каждое ключевое слово по отдельности, представлен отдельным классом-вариантом абстрактного класса Token (или лучше думать про него как про enum Token?) Это для того, чтобы парсеру команд (statements) было удобно кастовать токены к конкретным типам.

Statements

Кульминация, парсер собственной персоной. Вместо тысячи слов, пару сниппетов:

Про бинарный формат

Глобально файл базы поделен на блоки, и размер файла кратен размеру блока. Размер блока по умолчанию равен 12 КиБ, но опционально может быть увеличен до 18, 24 или 36 КиБ. Если Вы дата сатанист на магистратуре, и у вас очень большие данные — можно поднять даже до 42 КиБ.

Блоки пронумерованы с нуля. Нулевой блок содержит метаданные обо всей базе. За ним 16 блоков под метаданные таблиц. С блока #17 начинаются блоки с данными. Указателем на блок называется порядковый номер блока

Метаданных базы на текущий момент не так много: название длиной до 256 байт и кол-во блоков с данными.

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

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

Указатели на блоки работают по принципу указателей в inode. Об этом прекрасно писал Таненбаум и дюжины других уважаемых людей. Таким образом, таблицы видят свои блоки с данными как «страницы». Разница в том, что страницы, идущие с точки зрения таблицы по порядку, физически располагаются в файле как бог на душу положит. Проводя аналогии с virtual memory в операционках, страница: virtual page number, блок: physical page number.

Блоки данных не имеют конкретной структуры сами по себе. Но когда их объеденить в порядке, продиктованном указателями, они предстанут непрерывным потоком записей (record / tuple) фиксированной длины. Таким образом, зная порядковый номер записи, извлечь или записать её — операция практически константного времени, O(1 * ), с амортизацией на выделение новых блоков при необходимости.

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

Операция /update всегда делает перезапись «in-place», а /delete только подменяет первый байт. Операция VACUUM не поддерживается.

Про операции над таблицами, RowSet и джойны

Пришло время прочно скрепить лучшее из двух миров несколькими мотками скотча.

MC справа — драйвер БД, оперирующий над записями по одной за раз, используя порядковый номер внутри таблицы как идентификатор. Только он знает, какие таблицы существуют, и как с ними работать.

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

Затем, трек с символическим названием /drop. В домашней версии демо-записи происходит следующее: 1) найти дескриптор таблицы по имени; 2) обнулить. Кого волнуют неосвобожденные блоки со страницами данных?

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

Далее речь пойдет про работу с записями таблиц, поэтому позвольте сразу представить нашего рефери: RowSet.

Главный конкретный подвид этого зверя — TableRowSet — занимается выборкой всех живых (не удаленных) записей по порядку. Прочие разновидности RowSet в dropSQL реализуют необходимый минимум реляционной алгебры.

Оператор реляционной алгебры	Обозначение	Класс
Проекция	π(ID, NAME) expr
Переименование	ρa/b expr
Выборка	σ(PRICE>90) expr
Декартово произведение	PRODUCTS × SELLERS
Inner Join (назовём это расширением)	σ(cond)( A x B )

Кроме того ещё есть программируемый MockRowSet. Он хорош для тестирования. Также, с его помощью возможен доступ к мастер-таблице под названием «/autism«.

Два последних: /update и /delete используют наработки предшественника. При чем /update применяет технику, похожую на описанный выше «transition_vector».

Такой вот концерт! Спасибо за внимание! Занавес.

Хотелки

Пока что не сбывшиеся мечты:

Источник

Какую СУБД выбрать и почему? (Статья 1)

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

Нужно обязательно сделать ремарку, что некоторые крупные производители, имеют в своем арсенале несколько типов СУБД, как в виде отдельных продуктов, так и в виде внутренней реализации. Например, у Oracle на самом деле чего только нет, начиная с классической реляционной СУБД, продолжая с отдельным продуктом Oracle NoSQL Database, который может использоваться и как документная, и как колоночная, и как ключ-значение. Отдельное решение от того же Oracle, Autonomous Data Warehouse – это уже специализированное решение для хранилищ данных. Еще один отдельный продукт от Oracle – Oracle Graph Server для работы с графами, и еще много другого. Этому можно посвятить отдельную серию статей.

Реляционные СУБД

Начнем по порядку, классические, реляционные СУБД чаще всего используются для построения решений OLTP (Online Transaction Processing). В таких решениях СУБД работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом от системы требуется минимальное время отклика, а так же возможность, при определенных условиях, отменить любые изменения выполняемых в рамках транзакции. Если вы строите систему, в рамках которой требуется хранить значительное количество сущностей (таблиц), с различными типами связей между ними (один-к-одному, один-к-многим, многие-ко-многим), то это скорее всего про реляционные СУБД.

Когда выбирать реляционную СУБД

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

Когда не выбирать реляционную СУБД

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

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

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

СУБД типа ключ-значение

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

Когда выбирать СУБД ключ-значение

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

Когда не выбирать СУБД ключ-значение

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

Документные СУБД

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

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

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

Известными представителями таких СУБД являются CouchDB, MongoDB, Amazon DocumentDB.

Когда выбирать документную СУБД

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

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

Когда не выбирать документную СУБД

Не самое лучшее решение для реализации транзакционная модели, и точно не лучший вариант для формирования отчетности.

Графовые СУБД

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

Когда выбирать графовые СУБД

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

Когда не выбирать графовые СУБД

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

Колоночные СУБД

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

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

Когда выбирать колоночные СУБД

Когда не выбирать колоночные СУБД

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

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

Итоги

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

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

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

Итак, в таблице представленной ниже, кратко собрано то, что описано выше в статье.

Тип СУБД

Когда выбирать

Примеры популярных СУБД

Нужна транзакционность; высокая нормализация; большая доля операций на вставку

Oracle, MySQL, Microsoft SQL Server, PostgreSQL

Задачи кэширования и брокеры сообщений

Для хранения объектов в одной сущности, но с разной структурой; хранение структур на основе JSON

CouchDB, MongoDB, Amazon DocumentDB

Задачи подобные социальным сетям; системы оценок и рекомендаций

Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid

Хранилища данных; выборки со сложными аналитическими вычислениями; количество строк в таблице превышает сотни миллионов

Vertica, ClickHouse, Google BigTable, Sybase \ SAP IQ, InfoBright, Cassandra

Надеюсь данная статья оказалась полезной.

В следующих статьях посмотрим на выбор между облачными и on-premise СУБД, платными и бесплатными, и многое другое.

Источник

GRAMOPOD.RU

Статьи об ИТ в образовании

База данных: как создать самому. Пошаговая инструкция

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

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

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

Свидетельства о госрегистрации баз данных приравниваются к научным публикациям (Постановление Правительства РФ от 24.09.2013 N 842 (ред. от 01.10.2018, с изм. от 26.05.2020) «О порядке присуждения ученых степеней»), поэтому на них ссылаются в диссертациях, отчётах, статьях, указывают в резюме и портфолио. Кроме того, свидетельство служит подтверждением квалификации сотрудника при проведении аттестации.

База данных: что это такое?

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

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

База данных — это одна или несколько таблиц, в которые заносится информация. Количество столбцов в таблицах и их тип определяется пользователем — автором базы данных.

Как можно создавать базы данных

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

Систем управления базами данных много. Среди них: Microsoft SQL Server, Oracle Database, PostgreSQL, MySQL, SQLite. Для простых и небольших баз данных уровня лаборатории/кафедры/школы подойдут бесплатные OpenOffice.org Base или LibreOffice Base.

Как создать базу данных в LibreOffice Base

LibreOffice — бесплатный пакет офисных программ. Является альтернативой коммерческому Microsoft Office.

Мы создавали эту инструкцию для LibreOffice 6.4. Чтобы не было расхождений при создании базы данных по этому руководству, рекомендуем работать с LibreOffice версии 6.1 и выше.

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

Шаг 1. Запуск программы и подготовка

Запустите программу для создания баз данных LibreOffice Base.

В появившемся окне Мастера баз данных выберите Создать новую базу данных, укажите формат Firebird встроенная, нажмите Далее.

Шаг 1 Мастера базы данных

На втором шаге Мастера установите флажок в Открыть базу для редактирования, нажмите Готово.

Шаг 2 Мастера базы данных

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

Диалоговое окно сохранения файла базы данных

Шаг 2. Создание таблиц

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

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

В нашем примере два вида информации: термин и раздел дисциплины, для которой создаётся словарь. Каждый термин относится к определённому разделу дисциплины, поэтому надо установить связь между будущими таблицами.

В окне редактора базы данных кликните на Создать таблицу в режиме дизайна…

Пункт меню Задачи окна базы данных для создания таблицы в режиме дизайна

В появившемся окне добавьте характеристики столбцов таблицы для разделов дисциплины:

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

Сохранение таблицы Разделы

Закройте окно со структурой таблицы Разделы.

Сохраните базу данных (Файл — Сохранить).

Для создания второй таблицы с терминами опять кликните на Создать таблицу в режиме дизайна… и введите параметры столбцов таблицы:

Проверьте указанную структуру с изображением ниже.

Структура таблицы Термины

Сохраните таблицу под именем Термины, закройте окно структуры таблицы.

Сохраните базу данных.

Окно со списком таблиц базы данных

Шаг 3. Создание связи между таблицами

В главном меню программы выберите пункт Сервис — Связи..

Пункт меню программы для установления связей между таблицами

Далее с помощью окна добавьте обе таблицы для установления связей между ними.

Окно для добавления связей между таблицами

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

Для этого левой кнопкой мыши установите курсор на столбце Номер таблицы Разделы и, не отпуская кнопки, ведите курсор к столбцу Раздел таблицы Термины. Отпустите кнопку мыши. В результате таблицы будут соединены ломаной линией. На одном конце линии будет 1, а на другом — n. Это указывает на тип связи один-ко-многим, что означает, что к одному разделу может относиться много терминов.

Созданная связь типа один-ко-многим между таблицами Разделы и Термины

Сохраните образованную связь (Файл — Сохранить) и закройте окно.

Сохраните базу данных.

Шаг 4. Ввод данных в таблицы

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

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

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

Поздравляем — ваша первая база данных создана!

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

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

Шаг 5. Создание формы для добавления и просмотра данных

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

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

Чтобы начать создание формы, в левой части окна базы данных выберите раздел Формы. Кликните на Создать форму в режиме дизайна…

Меню для создания форм базы данных

Выберите пункт меню Форма — Навигатор форм… В результате появится маленькое окно со списком форм.

Окно создания формы в режиме дизайна, Навигатор форм

Создание главной формы для работы с разделами

Создайте главную форму для работы с разделами. Для этого правой кнопкой мыши щёлкните на пункте Формы и в контекстном меню выберите Создать — Форма.

Создание новой формы

Правой кнопкой мыши кликните на созданной форме в Навигаторе форм. Далее в контекстном меню выберите Свойства.

В окне свойств формы на вкладке Общие введите название формы «Форма Разделы». На вкладке Данные укажите Тип содержимого —Таблица, в поле Содержимое введите имя таблицы — Разделы, отключите Панель навигации. Остальные настройки не меняйте.

Сохраните форму базы данных (Файл — Сохранить), введите название формы.

Проверьте активность Мастера элементов управления в меню Форма. Кликните на этом пункте, если он не активен.

Пункт Мастера элементов управления меню Форма

В главную форму добавим таблицу для просмотра и редактирования разделов. Для этого установите курсор мыши на элементе Форма разделы в Навигаторе форм.

Выберите пункт главного меню Форма — Таблица. В левой части окна формы курсором мыши нарисуйте таблицу. В появившемся окне с помощью кнопки =>> добавьте все поля таблицы в созданный элемент управления.

Поменяйте Привязку у таблицы с Как символ на К странице, чтобы можно было перемещать её в любое место формы.

Изменение Привязки элемента формы

Столбец Раздел сделайте шире. На названии столбца Номер кликните правой кнопкой мыши и в контекстном меню выберите Столбец….

Вызов контекстного меню для столбца таблицы

В появившемся окне настроек укажите 0 в пункте Точность, затем закройте окно.

С помощью Вставка — Текстовое поле добавьте на форму подпись с текстом РАЗДЕЛЫ и отформатируйте на свой вкус.

Чтобы посмотреть, как работает созданная форма, отключите Режим разработки в меню Форма.

Чтобы вернуться к редактированию формы выберите пункт Режим разработки повторно.

Создание подчинённой формы для работы с терминами

Чтобы создать форму, подчинённую главной форме с разделами, кликните правой кнопкой мыши на Форма Разделы в Навигаторе форм, и выберите пункт Создать — Форма.

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

Нажмите на кнопку с тремя точками напротив пункта Связь с главным полем. В появившемся окне выберите поле Раздел для таблицы Термины и Номер для таблицы Разделы.

Напротив свойства Сортировка кликните на кнопке с тремя точками и в появившемся окне укажите Имя поля — Термин, а Порядок сортировки — по возрастанию.

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

В свойствах первого текстового поля укажите Поле Термин в Имя. Во вкладке Данные выберите Термин в свойстве Поле данных. Укажите Нет в свойстве Пустая строка — NULL, чтобы программа не разрешала сохранять термины с пустыми названиями.

Выберите второе текстовое поле. Укажите Поле Определение в свойстве Имя. В свойстве Тип текста укажите Многострочный. Поле данных — Определение. Остальное не меняйте.

В свойстве Имя третьего текстового поля укажите Поле Источник. Поле данных — Источник. Остальное не меняйте.

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

На следующем шаге укажите Раздел в качестве Отображаемого поля. Кликните Далее.

На последнем шаге Мастера укажите Раздел для Поле из таблицы значений и Номер для Поле из таблицы списка. Кликните Готово.

С помощью Форма — Панель навигации разместите на форме элемент, позволяющий перемещаться по записям таблицы с терминами.

Для всех элементов подчинённой формы добавьте подписи с использованием Вставка — Текстовое поле. Оформите на свой вкус.

Ваша форма должна выглядеть примерно так:

Скриншот созданной формы

Сохраните форму с использованием Файл — Сохранить. Закройте окно редактирования формы.

Два раза кликните на созданной Форма добавление в разделе Формы базы данных. Так созданная форма откроется для работы с таблицами базы данных. Перемещаясь по строкам таблицы с разделами, вы делаете активным один из них.

Чтобы изменить форму, кликните правой кнопкой мыши на её названии и в контекстном меню выберите Правка…

Итоги

Мы рассмотрели, что такое базы данных и зачем они нужны.

Мы научились создавать простую базу данных в бесплатной программе LibreOffice Base. Создали две таблицы, установили между ними связь. Для наполнения базы данных и просмотра её содержимого мы создали форму.

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

Источник