Базы данных (БД)

Содержание

Предисловие
Поиск информации
Индексация
СУБД
Подходы к классификации
Терминология
Нормализация
Типы данных и полей: единство и отличия в разных СУБД
Этапы разработки
Отчеты
Справочники
Словари синонимов
SQL
Примеры БД
Темы для разработки структуры

Предисловие

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

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

Значительная часть учебных материалов основана на MS Access (а, скорее, жестко привязана), который нельзя воспринимать, как реальную СУБД.


Доступ к этим материалам предоставляется только зарегистри­рован­ным пользователям!


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

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

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


Доступ к этим материалам предоставляется только зарегистри­рован­ным пользователям!


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

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

Ещё один момент. Стремление к тому, чтобы ограничить объем получаемых знаний, более, чем естественно: знаний слишком много. Крайне показателен, например, процесс защиты большинства диссертационных работ, когда бóльшая часть аудитории совершенно не понимает (и не пытается) понять, о чём идет речь.


Доступ к этим материалам предоставляется только зарегистри­рован­ным пользователям!


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

Прохождение мной обучения по курсу переподготовки в названной области больших данных, растянувшееся почти на весь 2020/21 учебный год, подтвердило самые худшие опасения. Теперь я могу указывать без кавычек терминологический набор: свалка, мошенничество, дилетантство... Слова «я не знаю, как это работает» в отношении излагаемого материала с попытками решить любые проблемы «методом тыка». «Это невозможно сделать» говорится о том, чем я пользуюсь повседневно несколько десятилетий. Такова норма знания сегодняшних «гуру».

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

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

Этапы разработки

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

  1. Изучение исходных данных.
  2. Написание технического задания (ТЗ).
  3. Создание структуры базы данных и составляющих ее таблиц.
  4. Разработка пользовательского интерфейса для работы с БД, разработка типовых отчетов.
  5. Написание Справки и документации.

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

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

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

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

Различают реляционные (изначальные, составляющие абсолютное большинство), иерархические (NoSQL, IMS), сетевые (IDMS) модели данных и соответствующие этим моделям СУБД. Также можно выделять


Доступ к этим материалам предоставляется только зарегистри­рован­ным пользователям!


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

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

Более подробная информация по отдельным представителям приведена здесь.

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

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

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

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

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

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

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

Таблицы

Таблица БД обычно представляет собой файл, хранящий описание некой совокупности объектов или явлений.

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

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

....

Схематичное представление таблицы реляционной базы данных

Поле 1Поле 2...Поле i 
    Запись 1
    Запись 2
    ...
    Запись j

Литература, ресурсы

  1. Мейер М. Теория реляционных баз данных, М.: Мир, 1987, 608 с.
  2. Крёнке Д. Теория и практика построения баз данных. 8-е изд., СПб.: Питер, 2003, 800 с.
  3. Кнут Д.Э. Искусство программирования (The Art of Computer Programming) в 3-х томах, пер. с англ., 2005–2010.

Контрольные вопросы


Доступ к этим материалам предоставляется только зарегистри­рован­ным пользователям!


Задания


Доступ к этим материалам предоставляется только зарегистри­рован­ным пользователям!



Copyright © 1993–2024 Мацкявичюс Д.А. Все права защищены.
Никакая часть сайта не может быть воспроизведена никаким способом без письменного разрешения правообладателя и явной ссылки на данный ресурс.