Что хранится в файлах реляционной базы данных

Обновлено: 07.07.2024

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

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

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

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

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

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

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

Данные

Наша база данных будет состоять из двух таблиц: “ Student ” ( студенты ) и “ Class ” ( предметы ), и содержать в себе информацию, соответственно, о студентах и изучаемых ими предметах.

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

С учётом этой информации нормализуем данные следующим образом:

1. Таблица студентов будет иметь следующие поля:

идентификатор студента (Student ID);
имя студента (Student Name);
операционная система (Operating System);

2. Таблица предметов будет иметь следующие поля:

идентификатор предмета (Class ID);
название предмета (Class Name);
преподаватель (Instructor).

Теперь заполним обе таблицы данными:

Отношения между объектами

Теперь, используя имеющиеся данные, определим отношения и объекты этих отношений.

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

Атрибуты отношений: первичные и внешние ключи

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

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

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

Первичный ключ идентифицирует каждую строку в таблице.

Для установления отношения мы должны сопоставить каждому первичному ключу внешний ключ.

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

Каждая строка этой таблицы зачислений будет связывать два внешних ключа между собой:

идентификатор студента (Student ID) – внешний ключ, ссылающийся на идентификатор студента в таблице студентов;
идентификатор предмета (Class ID) – внешний ключ, ссылающийся на идентификатор предмета в таблице предметов.

Использование таблицы перекрёстных ссылок

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

Каждая строка получившейся таблицы однозначно определяется собственным первичным ключом – идентификатором зачисления ( Enrollment ID ).

Кроме первичного ключа, таблица содержит ещё два поля:

внешний ключ Student ID ссылается на первичный ключ Student ID в таблице студентов;
внешний ключ Class ID ссылается на первичный ключ Class ID в таблице предметов.

Заключение

В нашей сегодняшней статье мы изучили принципы организации реляционных баз данных. Слово « реляционные » можно определить как « характеризуемые отношениями », от латинского слова “ relatio ” – « отношение ».

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

Как же применить изученные нами примеры на практике?

Разумеется, для этого можно использовать специальные программы, которые известны, как « Системы управления реляционными базами данных » ( Relational database management systems , RDBMS ). Но это – материал для другой статьи.

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

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

Understanding Amazon Relational Database Service (RDS)

Важные аспекты реляционных БД

SQL (Structured Query Language) – основной интерфейс работы с реляционными базами данных. SQL стал стандартом Национального института стандартов США (ANSI) в 1986 году. Стандарт ANSI SQL поддерживается всеми популярными ядрами реляционных БД. Некоторые из ядер также включают расширения стандарта ANSI SQL, поддерживающие специфичный для этих ядер функционал. SQL используется для добавления, обновления и удаления строк данных, извлечения наборов данных для обработки транзакций и аналитических приложений, а также для управления всеми аспектами работы базы данных.

Целостность данных

Целостность данных – это полнота, точность и единообразие данных. Для поддержания целостности данных в реляционных БД используется ряд инструментов. В их число входят первичные ключи, внешние ключи, ограничения «Not NULL», «Unique», «Default» и «Check». Эти ограничения целостности позволяют применять практические правила к данным в таблицах и гарантировать точность и надежность данных. Большинство ядер БД также поддерживает интеграцию пользовательского кода, который выполняется в ответ на определенные операции в БД.

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

Соответствие требованиям ACID

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

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

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

Оставлю это здесь, может кому-то пригодится.

Для начала, надо разобрать, что же такое SQL, а так же, где, как и зачем применяется.

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

Считаю справедливым, что нужно дать определение РБД:

Реляционная база данных - это тело связанной информации, сохраняемой в двухмерных таблицах.

Напоминает адресную или телефонную книгу, в которой есть зависимости.

Такая адресная книга называется двухмерной (строка и столбец) таблицей информации.

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

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

БД обычно не состоят из одной таблицы, поэтому, мы добавим еще одну:

Ничего не изменилось: так же, набор атрибутов у определенных "лиц".

Если мы захотим найти всю информацию по этим трем людям, мы получим следующее:

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

Кроме того, первичные ключи гарантируют, что ваши данные имеют определенную целостность.

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

Строковые типы:

Типы с плавающей точкой (дробные числа) и целые числа:

Целые числа, дата и время:

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

Вернемся к определению SQL.

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

P.S.: если все же полезная инфа, могу написать еще парочку статей о простых запросах Select с условиями Where. Напишите в комментарии.

Лига программистов

362 поста 6.3K подписчиков

Правила сообщества

Правило 0. begin

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

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

Правило 3. end.

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

> Вся информация в строке привязана к какому-то одному атрибуту - он и будет называться Первичным Ключом.

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

Если кто-то действительно хочет изучить SQL, рекомендую начать не с постов на пикабу, а с вебинара MS 10774 Гурьянова и Самородова. Курс примерно 2012 года, но всё актуально и на сегодняшний день.

Вспоминаю золотые студенческие годы. Сдавали мы свежепридуманный ГосЭкзамен (не помню, как точно он назывался в 2002-м), специальность - Прикладная Математика (математика+программирование). Выпало мне сдавать вопрос "SQL" преподу от компьютеров сильно далекому, но в математике мощному. Никогда не забуду его слова и детям буду перессказывать. Он сказал, "я в этих ваших технологиях не умею, но ты, vaduha, если мне расскажешь так, чтобы я понял - поставлю зачет, не расскажешь - значит сам не знаешь нихера". Получил в тот день и зачет и мудрость.

Если бы я не знал материал, я бы ничего не понял.

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

Это два моих скромных совета

"Реляционная база данных - это тело связанной информации, сохраняемой в двухмерных таблицах" - Это неправильно

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

Упоминаешь "атрибут", а что это такое? Потом напишешь "кортеж" и догадывайтесь сами, что это?

> Реляционная база данных - это тело

Што? Какой-то непонятный изъёб, дабы придать тексту флёр академичности. Проще будь, ТС, тут тебе не хабр с яйцеголовыми. И да, хватит уже путать понятия данных и информации. Хранилища информации называются базами знаний. А БД в самом своём названии содержит подсказку.

Чет прям не знал бы что такое скуль, даже с ходу не заинтересовало бы-тут вообще хорошо бы начать с того, что скуль немного отличается по синтаксису в разных бд, если ты конечно не просто звезду фигачить собираешься, чуть про архитектуру того, куда ты хочешь(без этого никак, простите)-ну и дальше уже в селектики разные. ВЫБРАТЬ ТекущийСправочник.Наименование
ИЗ Справочник.Номенклатура КАК ТекущийСправочник
))) Надо хотя бы примеры писать, а то так не наглядно.
Типа select * from table t where t.name like '%федо%' ;

Ты б ещё сопромат сюда притащил!

Базы данных - почему бизнес их боится / избегает

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

Цепляние за эксель у многих происходит до последнего

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

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

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

А главное - не понятно где данные и как понять, что они защищены

В экселе - все понятно, вот файл, в нем закладки с табличками

А база данных это где?

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

А если база данных в "облаке"?

В газетах вон постоянно пишут про хакеров и как из облаков данные утекают

Тут все надежно, проверено мудростью предков, и есть панацея от всех проблем: ctrl+alt+delete

Когда для тебя SQL это не просто буквы

О печальной защите информации в 2017 году

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

Несмотря на кучу законов типа ФЗ-152 уровень защищенности персональных (и не только) данных к сожалению переживает по моим наблюдениям не лучшие свои времена.

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

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

На следующую уязвимость в конце зимы или весной в 2017 году я наткнулся совершенно случайно с помощью рекламы в Яндекс-Директе.

Попалась на глаза мне контекстная реклама одной фирмы, которая говорила, что есть филиалы во многих городах РФ. Что-то тогда меня заинтересовало и я открыл их сайт.

Там открыл форму обратной связи.

С удивлением замечаю попадаю на сайт без домена, а только IP-адрес сервера.

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

Открываем файл конфигурации из Web-папки … Видим логин и пароль от FTP-другого сервера.

Проверяем… И попадаем уже во второй сервер…

Там тоже поднят WEB-сервер и вообще файлов намного больше… на 200 гигабайт с лишним. В основном это конечно бэкапы баз, но и очень много рабочих и свежих документов.

Внутри конфига WEB-сервера уже засвечивается и SQL-сервер с логином и паролем, который крутится на этом сервере. И да. На него тоже можно попасть.

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

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

В голове вместе с алгоритмом парсера и количество срок кода росла также лень всё это делать. Тогда я решил проверить теорию с предыдущим сервером. И.. Вы не поверите! Ситуация практически повторилась! Мы опять попали на FTP сервер, но на этот раз там лежал файл VPNRouter_64.vmdk. Виртуальная машинка.

Немного колдуем над файлом и получаем доступ к разделу виртуального диска внутри машинки.

Самое интересное, это папка OpenVPN с настроенной конфигурацией и сертификатами.

Копируем на свой комп, подключаемся, и… Бинго! Мы внутри защищенной сети.

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

Открываем терминал, запускаем nmap сканируем всю подсеть на 80,21,1433 порты.

Есть несколько компьютеров с такими открытыми портами!

И опять нас радостно встречает FTP без пароля на одном из серверов!

А дальше классика. Открываем Web.config, получаем строку подключения к серверу и с помощью dBeaver мы получаем доступ к базе данных внутри сети. Что еще интереснее, данная комбинация подошла и на другие SQL-сервера внутри этой сети. Один пароль на все сервера (всего их было 3-5 серверов, уже не помню). И это довольно крупная бюджетная организация для нашего региона!

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

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

Еще один случай опять же на работе, опять же в этом году.

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

В таком режиме мы уже работаем давно, но программист написавший программу уже уволился, а неудобства с программой проявляются все сильнее и мысли написать свою программу типа плагина или хотя бы нужные скрипты. И тогда я решил провести один эксперимент, а именно попробовать подключиться не через их прогу, а через редактор БД. Выдергиваю, по какому адресу их программа стучится, вбиваю в редактор БД, и… сервер нас впустил! Ему хватило подключения по VPN и доверительное соединение! Мы опять получаем доступ к серверу ко всем базам, которые там находятся со всеми вытекающими, куда по идее мы не должны были попасть.

Похожая ситуация и в самой корпоративной сети, опять же в этом году.

Дали программу, файл реестра, внутри которого… Логин sa, пароль 111111As…. Доступ из внешки… Ну хоть не на стандартном порту. А на нем так же крутиться персональная информация! Любой админ из корпоративной сети сути может увидеть инфу другого филиала через SQL-редактор, к которой он не должен иметь доступа, а так же изменить/удалить всю БД! А то что изначально дали доступ без защищенного канала еще хуже! Благо щас перевели программу на Vipnet, но пару месяцев назад доступ по внешнему IP еще был, может и до сих пор есть.

Недавно проводил исследование одного Android-приложения (мой предыдущий пост), там такая же плачевная ситуация. Любой школьник может получить доступ к информации без авторизации, слить бюджет на СМС, зафлудить СМС чей нибудь телефон, исказить рейтинг, слить базу данных. Так же существует возможность получить права баристы простым брутом пароля!

Это всё печально дамы и господа. Давайте, мы будем относиться к защите наших серверов/ПК/телефонов более серьезно. Для проникновения внутрь не понадобились никакие эксплоиты, хакерские навыки. Только штатные программы и любознательность.

А сколько подобных серверов с открытым доступом в интернете? А сколько еще таких дырявых приложений в Маркете? Наверно тысячи, десятки тысяч.

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

Многие этим профессионально занимаются, пишут ботов которые ползают по интернету, пробивают стандартные порты, брутят по словарю, ломают роутеры, IP-камеры, увеличивая армию ботов. С такими ботами встречался и я, точнее мой Firewall и было занятно наблюдать как пытались подобрать пароль от моей базы по примерно по 5-10 запросов в секунду.

Так же попадались боты которые пытались ломануть мой FTP и VNC сервер из разных стран.

Обнаружив эти попытки в логах, я убрал компы за NAT и с тех пор я держу все порты закрытыми, оставив только порт для VPN-соединения, а при, необходимости временно доступа другим людям, открываю временно их на нестандартных портах. Для постоянно доступа использую OpenVPN и генерирую сертификаты на каждое устройство.

Итак. Для минимальной безопасности:

1. Не держите FTP сервер с возможностью подключаться анонимусом. Не держите на FTP какую либо инфу, позволяющая скомпрометировать другие сервера. Конечно, если это Web-сервер и через FTP обновляется его содержимое, то дайте ему минимальные права, если его вдруг вскроют.

2. Не используйте простые пароли, которые можно легко сбрутить. Поверьте, боты не спят и рано или поздно могут приняться за ваш сервер, если он виден извне.

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

5. Не оставляйте в приложениях права админа, например в веб-приложениях, десктопных. Старайтесь давать минимальные права приложениям. Фукнции авторизации желательно вешать на сервер, а дальше посылать только ID-сессии, а не UserID. При обмене данными всегда проверять авторизована ли машина или нет. Особенно это касается Web- и Android-приложении.

6. Периодически проверяйте логи приложений, а так же лог фаервола.

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

8. Ну про своевременную установку патчей и обновлений, я думаю не стоит объяснять.

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

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