Проектирование баз данных: этапы и основы
Проектирование баз данных — это последовательный процесс адаптации доступных знаний и инструментальных средств для представления и обработки информации.
Реальная область применения, конкретная задача, описание входящего информационного потока и общие представления о процессе обработки информации поэтапно складываются в определенное концептуальное представление о том, что такое база данных в конкретном случае и как с ней работать.
Современная база данных
Реляционные отношения лежат в основе любой информационной модели. Решения от Oracle эквивалентны MySQL по сути, но они кардинально различны по многим аспектам. Проектирование баз данных — это также вопросы безопасности, объема информации и меры ответственности за достоверность данных, но они вторичны в контексте вопроса проектирования эффективной, надежной и удобной в пользовании базы данных.
Таблицы Excel — ничем не отличаются от Oracle и MySQL в контексте прямоугольных (реляционных) конструкций: столбцы и строки = одна ячейка на пересечении имени столбца (поля) и индекса выборки (строка). Если не учитывать меру и объем ручного труда, то, благодаря развитым средствам объединения ячеек по вертикали и горизонтали, Excel опережает даже Oracle!
Excel, по его основной идее, никогда «не светит» динамика, функционал Oracle, и перенести что-то с одного листа на другой «по остаткам» он не может. Здесь Oracle перспективнее, но ее соображения по вопросам миграции больших объемов информации и объединению формализованных позиций из различных источников оставляют желать лучшего. Здесь MySQL перспективнее: она не ставит перед собой глобальных задач, но свою работу исполняет отменно.
Реляционные отношения удобны, практичны и наработанные инструментальные средства, от частных решений уровня Excel до глобальных объемов Oracle, используются повсеместно, востребованы и у них есть, гарантированно обеспеченное работой, будущее.
Современная БД — это таблицы, строки, столбцы и индексы, окруженные полным функционалом, развитыми дополнительными средствами, учитывающими множественные операции, большие нагрузки и огромные объемы.
Знания и опыт современных систем управления базами данных (СУБД) учитывают не только вопросы надежности работы, достоверности данных, регламентации доступа и решение вопросов безопасности, но и дают возможность отслеживать негативное внешнее влияние, анализировать возможные атаки и попытки умышленного нанесения вреда.
Современная БД — надежный фундамент любого веб-ресурса и локального приложения, возможность миграции информации, трансформации и передачи данных, пересечение и объединение различных представлений.
Единственное существенное условие: высокая квалификация разработчика. Выполнить эффективное проектирование реляционных баз данных доступно специалисту, а чаще коллективу специалистов и экспертам области применения решаемой задачи.
Область применения, возможное решение и препятствия
Информация циркулирует везде. Многие проекты прямо связаны с интернетом, но фактор наличия формального представления данных здесь не лучше фактора неопределенности при создании веб-ресурса для сталелитейного завода.
Развитие и массовый интерес к интернет-магазинам не дает оснований и возможности перенести опыт создания одного магазина на создание другого. Фактор коммерческой тайны создает множество препятствий переносу знаний, хотя, по сути, следует разделять собственно магазин от программных инструментов, созданных для этого магазина.
Безусловно, заказчик заплатил и код сайта — это его собственность. Характерная черта современности: перенос знаний и наработок между однотипными задачами и смежными областями применения — невозможен и это проблема.
Парсинг — обширный спектр приложений для систем управления базами данных. Прежде всего — это сканирование информации из интернета. Не менее важно сопоставлять информацию, накапливаемую в базе данных, и запросы посетителей веб-страниц.
Анализ ключевых слов также сопряжен с необходимостью сформировать оптимальное решение, но проектирование баз данных на Access может оказаться перспективнее, чем на MS SQL Server или Oracle.
Список источников информации может быть динамичным. Динамика может быть свойственна таблицам базы данных источника, именам полей таблиц и правилам обращения (запроса). Проектирование реляционных баз данных по множеству источников однозначно вынуждает вести разработку от исходных данных, а не от оптимальной организации собираемой информации.
Есть два момента, которые присущи любой базе данных:
- ориентация на наполнение, алгоритм динамичного формирования базы данных в приоритете;
- ориентация на использование, структура базы данных важнее и на ее базе строится алгоритм использования информации.
В любой области применения существует формальная модель входящего информационного потока, модель хранения информации — собственно конструкция базы данных и модель (алгоритм) использования данных.
Различные процедуры и этапы проектирования
Основы проектирования баз данных обычно укладываются в три стадии. Различные специалисты по-разному именуют этапы работы, но, по сути, есть три позиции:
- концептуальное планирование;
- логическое проектирование;
- техническое исполнение.
Практика вносит свой вклад в сложившиеся традиции. Какой бы сложной ни была область применения и решаемая задача. Всегда требуется выбор правильного инструментария. Например, нужно собирать информацию от посетителей веб-ресурса, но сопоставлять ее требуется с данными из MS SQL Server. Веб-ресурс размещен на хостинге, на базе FreeBSD (интернет, сервер Apache), а MS SQL Server в другом городе доступен по распределенной сети компании.
В данном решении требует сначала решить частную задачу: наладить обмен данными с внутренним сервером.
Техническое исполнение общей задачи в обязательном порядке окажет влияние на начальный этап: редко когда проектирование баз данных удается выполнить с чистого листа. Даже по отработанной технологии решения задач, область применения развивается, всегда требуется сделать что-то иначе, чем это предполагалось изначально.
В последнее время многие теоретики и практические специалисты оперируют сущностями, как особыми данными. Это абстракции, которые позволяют описать модель информации на входе, в процессе обработки и в окончательном результате — базе данных.
Представления о данных и сущности
Проектирование БД через абстракции и сущности: возможность создать информационную картину, определить типы данных и связи между ними.
Обычно такое проектирование модели базы данных заканчивается графической моделью, применением MS Visio или изобразительных средств избранной СУБД. У Access свой вариант формирования информационной картины, у MySQL — свой, а некоторые системы управления сайтами вовсе скрывают базу данных, навязывая разработчику модель данных через свои собственные сущности — объекты решаемой задачи.
Характерная черта многих систем управления сайтами (CMS) — они делают «заявку» на уровень большей абстракции при описании информационной области решаемой задачи. Реальная база данных скрыта, CMS предлагает разработчику собственное представление о информационной картине мира.
В результате, этапы проектирования баз данных сводятся к соблюдению принципиальных требований и исполнение шагов предложенных создателями конкретной CMS. Нет ничего зазорного в использовании идей баз данных и их проектирования от Symfony или Bitrix, Zend или Yii, но для разработчика — это «обуза».
В идеале, средства проектирования баз данных должны быть избраны и применены индивидуально, без учета стороннего мнения, но с применением накопленного опыта и знаний.
Идеально, когда разработчик имеет сертификат от Oracle, но вполне приемлемо, когда квалификация разработчика включает в себя представления об информационных идеях Oracle и практические знания по применению MySQL.
В сложных проектах и распределенной обработке информации важна не только база данных, но и источники информации, представления о нуждах потребителей.
Этапы или коллектив: баланс приоритетов
Требование системности имеет самое непосредственное значение. Основы проектирования баз данных включают в себя также этапность работ, мониторинг промежуточных результатов, переосмысление каждого исполненного этапа на основании исполнения следующего вида работ:
- системность;
- этапность;
- обратная связь с любого момента времени, до самой начальной позиции.
Эти положения абстрактны, но присутствуют в любой теоретической и практической технологии создания эффективной базы данных.
Никакая технология не развивается сама по себе, ее двигают вперед люди. Квалификация коллектива разработчиков имеет важное значение. Информационная модель базы данных — это не только каркас, но и информационные потоки.
Что приоритетнее: красивая графика в представлении структуры базы данных или точное описание информационных потоков в динамике — вопрос не только поставленной задачи и области применения, но и мнение коллектива разработчиков в динамике.
Кадры решают все, но в контексте: концептуальное проектирование базы данных решает все квалификация. Все люди уникальны, а в области информационных систем существуют и развиваются представления конкретных людей.
Важно сформировать коллектив разработчиков, а не мифические этапы проектирования баз данных, предложенные авторитетным экспертом. Авторитет этого специалиста сформировался на базе конкретных работ, в конкретное время. Выполнить работу нужно сегодня, новая задача, современное оборудование, свежие технологии, …
Возможен обратный вариант. Есть Excel и Access и «обильные» данные в этих форматах с давних времен, когда еще был жив и здравствовал Windows for Workgoups. Частично остались данные dBase и Quattro. Сегодня эти слова уже забылись, но информация осталась, она востребована и нуждается в извлечении и формировании новых представлений.
Старое и новое: баланс знаний
Облачные технологии не чета тем базам данных, что делала компания Ashton-Tate. То что когда-то купила Oracle, никак не сопоставимо с тем, что она делает сегодня. Но в программировании с тех давних 80-х годов остались переменные, алгоритмы, функции, циклы и условия. Разве что понятие процедуры кануло в лету, а так все как было в древние времена, так и осталось.
Даже современные идеи объектно-ориентированного программирования облечены в классические синтаксические и семантические «оковы» прошлого века.
Что делать — программирование инерционно, а формализация информации и проектирование информационных баз данных — скорее процесс, нежели результат. Этапность работы — обязательное условие достижения результата. Но кто считал количество итераций с промежуточных этапов чуть ли не до начала работ?
Информация всегда динамична, ничто не стоит на месте: особенно предметная область задачи и требования пользователей. Каждый исполненный этап работ позволяет на новом уровне оценить уже сделанное и то, что предстоит сделать.
Рассматривать проектирование структуры базы данных как задачу и получить окончательный результат — бесперспективно. Как только БД будет сдана в эксплуатацию, обязательно появится новая идея, даже если инструментом создания базы данных был «простенький» Excel, а не фантастически мощный и многогранный продукт от Oracle, манипулирующий миллионами транзакций, сотнями тысяч одновременно работающих пользователей и террабайтами информации.
В приоритете не структура базы данных, а формирование квалифицированного коллектива специалистов плюс обязательное требования большей динамичности результата, чтобы по завершении работ не потребовалось обращаться к разработчикам, хотя бы пару месяцев.
Последовательное развитие и/или прыжки в высоту
Windows — не база данных, но в ней есть реликвия — реестр. Файл hosts — это просто идентификация IP-адресов локального компьютера и символических имен. Но через этот файл образуются информационные потоки с различных доменов или в различные СУБД.
Понять многоликий Windows как рабочий компьютер или сервер можно, но обосновать логику версий этого продукта не получится никак. PHP тоже не база данных, но аргументы разработчиков, почему за версией 5 сразу идет версия 7, не последовательны. PHP — это инструмент доступа к MySQL, его синтаксис определяет, как формировать запросы и получать ответы от базы данных при помощи диалекта SQL.
Примеры несовместимости современных инструментов программирования и обеспечения работы баз данных в последние годы стали нормой вещей, но это не самое оригинальное. Что будет за версией Windows 10? Какие перспективы идут вслед за Oracle Database 12c?
Информация разработчика-автора: «Oracle Database 11g Express Edition (Oracle Database XE) — это СУБД начального уровня, основанная на программном коде СУБД Oracle Database 11g Release 2. Данная СУБД бесплатна для разработки, развертывания и продажи, быстро скачивается и проста в администрировании».
Мнение разработчика-пользователя: «В 2013 г. компания Oracle выпустила версию Oracle Database 12c (версия 12.1.0.1), основными достоинствами которой стали снижение стоимости хранения, высокая доступность данных, простота консолидации баз данных и защита доступа к данным».
Реальная практика: объективное, результативное и эффективное логическое проектирование базы данных доступно только коллективу квалифицированных разработчиков. Получить работающий результат не сложно, сложно формализовать входящие потоки информации и определить оптимальный фундамент.
В мир плавных форм от точных прямоугольников
С приходом в свет объектно-ориентированного программирования, сериализация данных получила второе дыхание. Действительно, все вокруг — только лишь строки, желательно неопределенной длинны. Числа и даты — тоже строки символов.
Мощь и объективность реляционных отношений — бесспорна, но разве динамика колонок и строк наносит ущерб их репутации? Таблица — это просто данные, которые могут иметь шапку (список колонок) или не иметь строк. Пусть таблица — это просто совокупность данных, не обязательно именованная.
Совокупность данных может быть неоднородна и в ней можно обнаружить данные различной структуры. Принципиально, однородность данных свидетельствует о проработке области применения. Распределение данных по типам и видам — признак системности и объективного подхода, но допустить вероятность динамики структур все же целесообразно.
Если вывести проектирование и создание базы данных за пределы жестких конструкций и предположить, что таблица — это совокупность строк не обязательно однотипных и похожих по семантике друг на друга, то проектирование БД кардинально изменится.
Предметом работы станет не описание структуры базы данных, а динамика движения информации. Этапы работ распределятся на три центра тяжести:
- входной информационный поток;
- преобразования и движение информации внутри базы данных;
- выборка данных для использования.
Понятия структуры таблицы отсутствует. Нет ни строк, ни столбцов. Есть абстракция — данное, определенной структуры удовлетворяющее конкретной точке в алгоритме. Если более конкретно, то функция обработки информации требует определенную информацию в конкретном объеме.
Обязательное требование рекурсивности всех функций обработки информации и ориентация на функции, а не на данные, позволяет проектировать базу данных в динамике накопленной информации и входящего потока данных, которые используются по инициативе пользователя, процесса или иной функции.
Фактически: пришел сигнал на пользование, получен запрос на выборку, сработал триггер в приложении и входящая информация через то, что уже имеется, предоставила нужное решение.
Фундаментальные знания и жесткие конструкции
Знания — прерогатива человека, программы — бремя компьютеров. Разработчик волен применять знания так, как сочтет нужным в конкретной ситуации. Обычный человек использует массу баз данных, не придавая этому значения. Как организованы базы данных в голове обычного человека, никто не знает, но каждый знает, как он ведет свои дела, где что записывает, как что находит, и когда нужно использует.
Результат работы программиста — на уровне программки на «Бэйсике», которая через ODBC извлекает данные с сайта интернет-магазина, эквивалентен титулованному разработчику Oracle, который делает запрос на выборку данных авиционно-космического салона «МАКС». Оба результата «застывают» в статике с момента завершения работы. Это не активные знания, которыми пользуется человек, в этом хранится секрет создания системы проектирования баз данных.
Алгоритм не может быть фиксированным. Все должно быть определено в динамике. Заслуги квалифицированных разработчиков несомненны, но лежат они вовсе не в изящных формах решений от Oracle, MySQL или ограниченного в возможностях Access. Иная таблица Excel может обеспечить динамичный контент и не требовать участия программиста более менее приличное время после завершения работ.
Вопрос в том, насколько качественно формализована динамика области применения, а не структура базы данных.
Живые решения
Невозможно планировать работу так, чтобы привязать к задаче коллектив профессиональных разработчиков. Не то чтобы коллектив обиделся, но это не правильный подход.
Задача на проектирование базы данных должна быть сформулирована так, чтобы разработанный функционал самосовершенствовался, накапливал знания и при исполнении своих «обязанностей» отталкивался не от кода, созданного специалистами, а от знаний, приобретенных посредством этого кода.