Информация основывается на отношениях. При пересечении отношений возникает новая информация. При таком нестандартном, но предельно простом подходе, удобнее всего смотреть, что сделано. Кроме того, станет очевидным, что именно будет сделано в будущем. В социально-экономической сфере важно предвидеть, а в отношениях между людьми важно принимать обоснованные решения. Реляционная модель данных, как идея прошедшая многовековой путь развития, интересна и поучительна для создания новых идей, принятия взвешенных решений и формирования новых общественных отношений.
Из истории идей «баз данных»
Идеи отделяются от авторов. Тем быстрее это происходит, чем актуальнее идеи. Они проходят мимо людей, когда уже существуют, а у последних только открылись глаза, и они что-то заметили. В программировании очень много событий, фактов и авторов, которым что-то приписывали или они сами говорили, что делали. Потом выяснялось, что сделано было совсем не ими или не так, как надо было.
Информация и программирование, как вселенная и атом, но последний по сей день не стремится стать фундаментом для развития информации, довольствуется пока малым: формальным отношением к делу - формализацией.
Базы данных человек создавал всегда. У него это называется знания и умения. В видимом воплощении это (все, что создано человеческим разумом): орудия труда, рисунки, тексты, документы, обычаи, нормы писанного права, библиотеки, здания, технические изделия и многое другое.
Появление компьютеров стало проблемой. То, что было всегда очевидно, просто не поддавалось формализации и воссозданию программным образом. Вероятно, именно смысловое наполнение термина «формализация» было не готово к переносу знаний и умений в программные изделия.
Из истории моделей баз данных
Отношения настолько привычны, что незаметны невооруженным глазом. Прямоугольные формы таблиц - беда, которая с самого первого момента, когда появилась первая электронная таблица, присутствует до сих пор даже в самой именитой системе управления базами данных.
Равноправие данных очевидно. Не требуется доказывать, что фамилии эквивалентны, имена - тоже. Если взять две студенческие группы, то в обеих будут фамилии и имена. Если взять поток, получится иерархия. Сначала вершина - поток, потом группы, потом уже каждый конкретный студент.
Совершенно не сложные рассуждения приводят к тому, что реляционная модель базы данных не единственная в своем роде, имеются также:
- иерархическая;
- сетевая;
- файловая;
- объектно-ориентированная.
Есть еще множество смешанных идей и еще большее количество реализаций, не нашедших своего применения. В любом случае есть отношения равноправия или иерархии. Ничего другого придумать невозможно. В любой системе отношения могут быть только на одном уровне: вверх (обобщение) и вниз (уточнение).
Важно: на самом деле все происходит по линии времени. Кроме «беды» с прямоугольными таблицами есть еще проблема с историей. На заре компьютерного дела и программирования про время никто так и не подумал. А ведь любое событие всегда происходит во времени.
Модели баз данных - это системы. С этим никто спорить не будет. Если так, то имеются только три вида отношений:
- по горизонтали - равноправие;
- по вертикали - иерархия;
- по времени - история.
Все остальные термины и детали можно применять, обсуждать, но они не будут иметь никакого объективного значения.
Основные понятия баз данных
Распределенная база данных или локальный файл с данными. Кластер, облако или виртуальный контейнер. Все это аппаратные или программные решения. Как расположено тело (содержимое базы данных) и организован функционал (программные модули, управляющие компьютеры и пр.) - это не база данных, а технические решения.
Если база данных развернута на рейде, когда достаточно одного винчестера, или когда веб-ресурс обеспечивает функционал базы данных, манипулируя данными с сотен тысяч других веб-ресурсов - это не база данных, а также технические решения.
Дополнительно (к обозначенным техническим решениям):
- современное аппаратное обеспечение надежно и прекрасно работает;
- имеется квалифицированный персонал, который может построить сколь угодно сложную и высокоорганизованную аппаратно-программную конструкцию сети (инфраструктуры компании или общего дата-центра);
- имеются разработчики, которые блестяще владеют технологиями развертывания приложений и доступа к данным.
Все это к модели баз данных имеет вспомогательное, хотя и существенное отношение.
Самое популярное понятие: база данных - это поименованная совокупность структурированной информации, относящейся к предметной области. Есть еще одно подобное понятие: ядром любой базы данных служит модель, отражающая, в первую очередь, структуру.
Часто сетевая и реляционная модель данных не только разделяется, как нечто кардинально различное, но и рассматривается как децентрализованная или централизованная система, у которой есть узлы, уровни, связи, к которой присоединяются конечные пользователи.
Собственно, что такое конечный пользователь? Есть бесконечный? Как говорил Булгаков, осетрина не бывает второй свежести. Аналогично пользователь бывает только одного вида, и он к модели данных, как бы она не именовалась, никакого отношения не имеет.
Элементы и характеристики баз данных
Самый ценный элемент - таблица. Всегда прямоугольная. В таблице есть поля и записи. Обычно каждая таблица помещается в свой файл, но часто все таблицы одной базы данных помещаются в один большой файл. С этой идеи (одного файла для одной базы данных) и началась идея использовать несколько компьютеров для одной громоздкой СУБД.
По сложившейся традиции поле-столбец имеет:
- имя;
- тип;
- описание типа;
- встроенную проверку соответствия значения типу;
- комментарий;
- триггер или встроенную процедуру.
Вариантов описаний полей не так много, но самая существенная его характеристика - это его тип. При желании имя всегда можно поменять, комментарий никогда не имеет значения, но вот поменять тип - это сложно, особенно на действующей базе данных.
Очень часто основные понятия реляционной модели данных конкретные разработчики именуют по-своему. В последнее время модно использовать термины:
- сущность;
- доктрина;
- информационный объект;
- реквизитный состав;
- взаимосвязи данных (один к одному, один ко многим, все ко всем).
Анализируя терминологию по описанию конкретных применений баз данных, можно сказать, что в ее основу ложится либо опыт коллектива разработчиков, либо конкретная предметная область. Обычно понять, что вкладывается, например, в слово «сущность» или «доктрина», можно только в конкретном применении. Об общем, признанном всеми критерии пока не может быть и речи.
В частности, никто не будет спорить, что Oracle - признанный лидер. Никто не скажет что-то плохое о MySQL, но над этими фундаментами властвует не мнение их создателей, а понимание «применителей»: конкретные программисты, применяя тот или иной продукт, «додумывают» элементы и характеристики базы данных, которую создают.
Прежде, чем начать моделирование
Знания и умения программиста должны быть достаточны, а если проектирование реляционной модели данных будет выполнять коллектив, должно быть обязательно полное взаимопонимание и отсутствие конфликтных ситуаций.
Есть всего два варианта развития событий:
- проектируется классическая модель;
- создается объектно-ориентированная модель (ООМ).
Отличия слов «проектируется» от «создается» в том, что в первом случае все идет по стандартному плану, который принят программистским сообществом и понимаем классическим заказчиком. Здесь есть работа, не творчество. Результат: надежная, безопасная и полностью работающая модель. Но здесь не будет динамики, самоадаптации и никакого развития.
Задача будет ставиться в контексте формализации предметной области и формирования таблиц, связей, запросов и обслуживающего функционала. При создании объектно-ориентированной базы данных задача будет выглядеть примерно так: все элементы реляционной модели данных - это объекты.
Если работа нужна простая или ее нужно выполнить предельно быстро, выбирается первый вариант. О создании объектно-ориентированной базы данных можно задуматься только в том случае, если есть время и возможность для творческого процесса. Да и то, следует тщательно все взвесить. В любом случае исполнитель и заказчик должны прийти к согласованному решению довести начатое дело до конца - это главное условие успешного завершения работ.
Основа проектирования: простое
Реляционная модель данных может быть создана при помощи существующих инструментальных средств, например для MySQL есть Workbench. Производитель каждой популярной базы данных предлагает свои инструменты, имеются десятки предложений от сторонних разработчиков. Основываться или нет на таких инструментах - дело вкуса и умений с ними работать. Если нет опыта, то лучше даже не думать. Если есть лишний месяц-другой, можно проконсультироваться с коллегами и принять решение.
Вопрос моделирования и проектирования - это бумага, карандаш и компьютер, например, с интерпретатором PHP, сервером MySQL и хостингом на Apache. Для Oracle или MS SQL Server вопрос разрешается аналогично, но бумага и карандаш - это надежная классика процесса.
Процесс моделирования и проектирования
Реляционная модель данных - это формализация предметной области задачи, но не следует повторять ошибочный опыт многих проектов. Далеко не все определяется количеством и качеством таблиц. Не все зависит от продуманности связей:
- один к одному;
- один ко многим;
- многие ко многим.
Совершенно не нужно думать о запросах: кто и когда, на каком join будет сидеть - на левом или на правом?
Из истории идей «человеческих» баз данных известно: он их создает постоянно и у него это называется знания и умения. Это не join и не «сколько к скольким». В классическом проектировании можно начинать моделировать со стороны запросов (это вывод) или со стороны таблиц (это ввод). Собственно, база данных - это система таблиц.
Слово «систематизация» относится к каждой таблице в частности и ко всем таблицам в совокупности. По ключам устанавливаются связи между ними, но это не вариант «сколько к скольким». Это осмысленная связь одной структуры данных к другой. При таком подходе семантика будет нагляднее, а результат - практичнее.
В классическом проектировании не требуется большего. В любом случае получится прямоугольный, но работающий вариант на плоскости. То есть естественная реальность - это три вида отношений:
- по горизонтали - равноправие;
- по вертикали - иерархия;
- по времени - история.
Полученная формальность - это только первые два. Если удастся продумать, как использовать линию времени, откат событий и хранить историю событий - хорошо. Но сомнительно, чтобы естественная информация в полноценном виде формализовалась при классическом проектировании.
ООМ: точка и система точек
Современный уровень знаний и умений не позволяет определиться с приоритетами. С чего начинать: с точки или с системы точек? Это, как в концептуальном философском вопросе: «Что было раньше - курица или яйцо»? В обоих случаях требуется вспомогательное условие. Скорее всего именно предметная область задачи поможет определить приоритет.
Часто реляционная модель данных может быть эффективнее смоделирована и создана именно с точки, поскольку система включает в себя подсистемы и создает требуемую иерархию отношений, обеспечивая на каждом уровне равноправные отношения. Однако есть множество задач, когда системы могут возникать одновременно, причем сразу на нескольких уровнях, а потом выстраиваться в общую систему. Например, веб-ресурс для парсинга информации с накоплением под каждого посетителя.
В такой задаче создать одну систему под всех посетителей неразумно. Не известно, сколько их будет и на каком уровне иерархии они окажутся в тот или иной момент времени. Совокупная характеристика реляционной модели данных здесь будет постоянно меняться. Чтобы принимать общее решение, нужно будет сливать данные в общую систему, которая будет перераспределять ответы соответственно сформированным уровням, а их количество тоже будет динамично меняться.
ООМ: создание
Для создания объектно-ориентированной базы данных достаточно одной таблицы. Изначально объектно-ориентированность означает активность. Следовательно, база данных здесь - место хранения. Но такой подход не даст нужной производительности, поскольку хранить всю базу данных в оперативной памяти малоперспективно при современном уровне развития технологий.
Как создать объектно-ориентированную базу данных? Это компетенция разработчика, главная задача которого - реализовать нужные знания и умения в виде системы объектов. При таком подходе таблицы теряют свою прямоугольность, работают все три вида отношений:
- по горизонтали - равноправие;
- по вертикали - иерархия;
- по времени - история.
Вопросы о том, какие будут связи и кто на каком join будет «сидеть», теряют всякий смысл. Разработчик создает систему объектов, которые сами по себе реализуют свои знания и умения с другими объектами. Здесь главное правило: объект - это реальный элемент информации из конкретной предметной области, которая дает ему нужные знания и умения.
Проблемы и перспективы
Реализовать идею ООМ сложно, об этом свидетельствует динамичное развитие лидеров отрасли, которые непрерывно обновляют свой «парк» прямоугольных инструментов, то есть развивают классические реляционные системы управления базами данных. Но естественная информация не укладывается в прямоугольные таблицы!
Мир информации - это реальные знания и умения, которые при современном уровне развития можно уложить в стройные системы объектов и сделать решения конкретных задач динамичными и саморазвивающимися.
