Описание данных

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

Самые общие рамки описания данных задаются реляционной моделью (см. “Реляционные БД”). В частности, именно она определяет необходимость организации данных в виде таблиц и накладывает дополнительные требования на устройство самих таблиц. На следующем уровне формализации полномочия передаются конкретной реляционной СУБД.

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

Типы данных

Поскольку в статье “БД и СУБД” понятие данных определено не строго, договоримся об используемой терминологии (отметим, упомянутая статья, в свою очередь, ссылается на словарь школьной информатики А.П. Ершова). От данных мы будем требовать, чтобы они были атомарными, т.е. неделимыми. Любая совокупность таких неделимых данных уже является структурой. Разумеется, здесь также приходится договариваться о том, когда остановиться в желании и возможности что-то “поделить”. Например, строку можно поделить на символы, в этом смысле строка, безусловно, является структурой данных. Но если договориться не делить строку на символы, то можно считать ее атомарной. Соответствующие термины неразрывно связаны с важнейшим понятием “тип данных”.

Когда говорят о свойствах сущности (объекта) (см. “Реляционные БД”), явно или неявно имеют в виду, что каждое конкретное свойство (в таблице — поле записи) принимает значения из некоторого множества. Указанное множество и называется типом данных.

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

Все реляционные СУБД поддерживают данные следующих основных типов:

· числовые;

· строковые;

· логические;

· даты.

Приведенный список не является исчерпывающим. Как правило, СУБД также имеют типы для хранения больших текстовых и двоичных данных, специальные “денежные” типы и т.д. На следующем рисунке — снимке экрана конструктора таблиц Microsoft Access — показаны типы, поддерживаемые этой системой.

Отметим также, что, как правило, типы могут снабжаться модификаторами, уточняющими соответствующее множество данных (диапазон значений). Например, в Microsoft Access данные числового типа могут быть просто “целыми”, “длинными целыми”, “вещественными” и т.д. — см. рисунок.

Границу между типом и типом с модификатором удобнее проводить в рамках конкретной СУБД. Обычно считают, что данные, для описания которых используется одно ключевое слово на языке SQL, принадлежат одному типу, а те, которые описываются разными словами, — разным (см. пункт “Язык описания данных”).

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

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

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

· Определение имен и типов полей. На этом же этапе обычно требуется установить специфические свойства конкретных полей — может ли поле содержать “пустые” (неопределенные) значения, каким должно быть значение “по умолчанию” и т.д.

· Определение первичного ключа. Несмотря на то, что реляционная модель требует наличия в каждой таблице первичного ключа, большинство СУБД позволяют не определять ключ в таблице. Этого, разумеется, следует избегать. К чести СУБД они практически всегда стараются “наставить разработчика на путь истинный” (см., например, рисунок).

· Определение (при необходимости) индексированных полей.

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

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

Язык описания данных

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

Об SQL чаще говорят, как о языке обработки данных (языке запросов), об этом рассказано в соответствующей статье (см. “Обработка данных” 2). Вместе с тем важно не забывать о том, что SQL — язык описания и обработки данных. В частности, именно в SQL определяется набор совместимых типов данных, обозначаемых соответствующими ключевыми словами (целые — INT, вещественные — FLOAT, строковые — VARCHAR, даты — DATE и т.д.).

Для создания таблиц в SQL имеется команда CREATE TABLE. На следующей иллюстрации показано описание таблицы “Friends” из трех полей в конструкторе Access.

А вот как выглядит определение той же таблицы на языке SQL:

CREATE TABLE Friends (

id INT NOT NULL,

name VARCHAR(50),

birthday DATE,

PRIMARY KEY(id)

)

Методические рекомендации

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

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

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

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