Что такое язык описания данных пояснить требования перечислить наиболее распространенные
Язык описания данных
В качестве примера описания данных рассмотрим ЯОД СУБД dBASE IV или FOXPRO. В данной СУБД элементы данных описаны следующими параметрами: номер элемента, имя, тип, длина значения элемента в байтах или символах, точность представления. Тип элемента принимается одним из следующих: символьный, целый, с плавающей запятой, дата, логический, поле памяти, графический.
Например, элемент “Высота” описывается следующим образом:
Следующим примером является ЯОД СУБД “ПОТОК”. В нем элемент описывается следующими параметрами:
ИМЯ (принятое по технологии);
ИНД (положение элемента в агрегате, т.е. относительный адрес в байтах);
РЗДЭ (символ, отделяющий данный элемент от следующего при вводе данных);
МАХ (максимально допустимое значение);
MIN (минимально допустимое значение);
ЕДН (единица измерения элемента);
РАЗМ (длина в символах при выводе);
ЗАГЛ (заголовок поля);
ГРН (правая граница поля, начиная с которой будет печататься элемент);
ТОЧН (количество знаков после запятой для выводимых чисел);
ЕДВВ (единица измерений для печати);
Тогда схема элемента “ВЫСОТА” будет следующей
ИМЯ “Н”, ТИП “Д”, ДЛИНА 4, ПРЗН 0, РЗДЭ “:”, МАХ 9000, MIN 100, ЕДН “М”, РАЗМ 9, ЗАГЛ “Н”, ГРН 2, ТОЧН 3, ЕДВВ “М”.
Агрегат также может быть описан определенным образом. Например в СУБД “ПОТОК” параметрами агрегата “РЕПЕР” приняты следующие величины:
НЗВН (количество единиц в имени агрегата)
КОЛВО (количество элементов в агрегате)
РЗДА (символ, отделяющий данный агрегат от следующего) и др.
Тогда описание имени агрегата “РЕПЕР” будет следующим:
НЗВН 8; КОЛВО 7; РЗДЭ “*”.
Схема всего агрегата тогда будет
описание имени агрегата
В примере с тахеометрической съемкой агрегатами являются: пикет, станции, исполнитель, участок, диспетчер, план. Примерами элементов: отсчет по горизонтальному кругу, вертикальному, высота, ФИО исполнителя, номер участка и др.
Язык описания данных
Языки описания данных состоят из двух составляющих: языка представления данных и языка описания метаданных. Языки представления задают формальные характеристики документов: форматы, кодировку, тип, структуру документов.
К языкам представления относятся прежде всего языки библиографического описания данных, применяемых при организации каталогов и картотек. На автоматизированный поиск рассчитаны машинные библиографические форматы. Их основу составляют форматы MARC (Machine-Aided Readable Cataloging) и ISO 2709. На современном этапе наиболее распространены международные форматы UNIMARC, американский MARC21 и в России RUS- MARC.
Международный коммуникативный формат предназначен для обмена библиографическими данными в машиночитаемой форме. UNIMARC определяет структуру и наполнение библиографических записей и включает «МАРКЕР» записи, «СПРАВОЧНИК», «ПОЛЯ ДАННЫХ».
Маркер записи 24-х символьный и, кроме всего прочего, содержит элементы, описывающие структуру справочника и полей данных. Справочник представляет собой перечень статей. Каждая статья справочника состоит из трех частей: метки поля, относительного адреса данного поля, длины поля. Например, Вестник Санкт-Петербургского университета будет иметь запись: 011 ##$a0132-4624.
Для электронных документов разработаны и используются следующие форматы:
1) текст, структурированный или нет (ISO 646);
2) текст на языке SQML (ISO 8879);
3) текст на языке HTML;
4) ODA-текст (ISO 8613);
5) CCIT-формат кодировки графических образов страниц;
7) мультимедийные составные файлы (текст, аудио, видео).
В связи с ростом Интернет найти необходимый ресурс становится все сложнее, использование форматов (UNIMARK, MARC21) в сети нереально, т.к.
Работы по стандартизации набора семантических свойств с ориентацией на электронные документы были активизированы в 1995 г. после семинара в Дублине (штат Огайо), в связи с чем вариант языка метаданных получил название Дублинского ядра. Текущая версия спецификаций Дублинского ядра включает 15 элементов или полей, которые могут повторяться. При описании поля кроме имени вводят понятия схемы и подполей.
Схема — это наименование правил, в которых оговаривается содержание полей. Например:
1) поле «Дата» — стандарт ввода дат;
2) поле «Язык» — стандарт кодировки ASCII, KOI8 и т.д.
Подполе — это информация, уточняющая содержание поля.
Перечень подполей еще четко не определен. При использовании стандарта DC описание ресурса может быть прочитано специальным роботом и помещено в каталог с разбиением на поля.
Кратко рассмотрим описание некоторых элементов Дублинского ядра (Dublin Согу Metadata Element Set).
1. Название ресурса.
Определение: имя, данное ресурсу автором или издателем.
Схема: не используется.
DC. Title — основное заглавие (подполе по умолчанию);
DC. Title Alternative — альтернативное заглавие.
2. Автор или создатель.
Определение: лицо или организация, ответственные за содержание ресурса.
DC. Creator — автор (подполе по умолчанию);
DC. Creator. Personal Name — имя индивидуального автора;
DC. Creator. Corporate Name — имя коллективного автора (включая наименование конференций);
DC. Creator. Personal Name. Address — любой тип адреса индивидуального автора, включая электронный;
DC. Creator. Corporate Name. Address — любой тип адреса коллективного автора, включая электронный.
3. Предмет и ключевые слова.
Определение: описание ресурса. Обычно предмет описывается ключевыми словами или фразами. Рекомендуется использовать контролирующие словари или формальные классификационные схемы.
Определение: описание содержания ресурса.
Остальные поля далее рассмотрим в порядке перечисления:
2. Издатель (пять подполей).
3. Сведения об ответственности (сведения об организации или лице, внесших значительный вклад в создание ресурса, но не указанных в поле «автор» или «создатель», содержит пять подполей).
4. Дата (согласовано только два подполя: «дата создания» и «дата поступления»).
5. Тип ресурса (текст, программы, изображения, перечень которых приведен в Интернете):
6. Формат используется при определении программного и технического обеспечения (doc, pdf, htm, jpeg). Для его определения рекомендуется использовать контролируемый словарь стандарта MIME (Multipurpose Internet Mail Extensions) — Internet Media Types.
7. Идентификатор ресурса (строка или число для однозначного определения ресурса).
8. Источник (строка или число для однозначного определения источника, из которого ресурс был создан).
Текст по умолчанию:
URL (Uniform Resource Locator):
ISBN (International Standard Book Number) и т.д.
10. Отношения (указываются другие ресурсы, на которые имеются ссылки).
11. Охват (пространственная и временная характеристика).
12. Правовые аспекты (источник информации об авторских правах).
Стандарт DC полностью соответствует стандарту HTML, и поэтому он может непосредственно включаться в сам ресурс. В языке HTML для этого используется специальный тег Meta с атрибутами NAME (название поля) и CONTENT (значение). В последних версиях HTML введены атрибуты LANG и SCHEME,
которые позволяют задать язык представления и соответственно схему, уточняющую контекст.
Стандарт DC достаточно прост, и для разработчиков ресурсов существуют сайты с формами для описания ресурса и набора метаданных, а также правил кодировки.
Описание данных
В обзорной статье “БД и СУБД” внимание читателя акцентируется на том, что в определении понятия “база данных” фигурируют как сами данные, так и способы их организации. Под “описанием данных” обычно понимается совокупность средств формализации указанных понятий.
Самые общие рамки описания данных задаются реляционной моделью (см. “Реляционные БД”). В частности, именно она определяет необходимость организации данных в виде таблиц и накладывает дополнительные требования на устройство самих таблиц. На следующем уровне формализации полномочия передаются конкретной реляционной СУБД.
СУБД не имеет права нарушать принципы реляционной модели, но может как конкретизировать технические параметры (например, определять диапазоны представления чисел и т.п.), так и предоставлять разработчикам и пользователям свои собственные уникальные средства, отсутствующие в других системах. Эти средства бывают очень удобными (собственно, на этом поле в основном и конкурируют СУБД различных производителей). Но, используя специфические для данной СУБД особенности, всегда надо иметь в виду возможность миграции БД в другую систему. Приведем короткий пример для иллюстрации сказанного. СУБД 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 (
Методические рекомендации
Применительно к описанию данных границу основной и старшей школы разумно провести между “понять описание” и “уметь описать”. В основной школе у учителя, как правило, нет возможности пройти с учениками весь путь проектирования БД. Поэтому имеет смысл только “препарировать” структуру небольшой, хорошо спроектированной БД. При этом есть возможность рассмотреть понятия “таблица”, “ключ”, “связь”. И, конечно, это очень удобный и уместный повод обсудить типы данных и акцентировать внимание учащихся на том, что тип определяет множество допустимых операций.
Не имеет смысла ограничиваться однотабличной базой данных. Конечно, такие базы имеют право на существование, но для целей обучения они малопригодны, так как не позволяют продемонстрировать целый ряд важнейших понятий.
В старшей школе можно провести полный цикл проектирования БД, начиная с построения инфологической модели. При переходе к даталогической модели появятся таблицы, которые придется описывать. На содержательном уровне границу между базовым и профильным уровнями здесь определяет степень сложности БД. На методическом — степень индивидуализации работы учащихся.
Проектируя вместе с учениками базу данных, очень важно не представлять все ее параметры заранее известными и определенными. Даже опытные разработчики много раз возвращаются к различным этапам проектирования — уточняют как даталогическую, так и инфологическую модель. Вполне можно в учебных целях о чем-то “забыть”, затем “обнаружить” несовершенство модели и уточнить ее. Это много эффективнее, чем сразу предъявить готовый “идеальный” образец.
Язык описания данных
57. Язык описания данных
Data definition language
Язык, предназначенный для описания схем без данных
Смотреть что такое «Язык описания данных» в других словарях:
Язык описания данных — высокоуровневый непроцедурный язык декларативного типа, предназначенный для описания физической и/или логической структуры данных. См. также: Системы управления базами данных Структуры данных Финансовый словарь Финам … Финансовый словарь
язык описания данных — ЯОД Язык, предназначенный для описания схем баз данных. [ГОСТ 20886 85] Тематики организация данных в сист. обраб. данных Синонимы ЯОД EN data definition languageDDL … Справочник технического переводчика
язык описания конфигурации системы — Данный язык обеспечивает возможность обмена информацией о конфигурации устройств в стандартизованном формате между программным обеспечением различных фирм производителей. [Новости Электротехники №3(75). Релейная защита. МЭК 61850] Все параметры… … Справочник технического переводчика
язык описания хранения данных — — [Е.С.Алексеев, А.А.Мячев. Англо русский толковый словарь по системотехнике ЭВМ. Москва 1993] Тематики информационные технологии в целом EN data storage description languageDSDL … Справочник технического переводчика
язык — 3.1.6. язык: Система знаков, обеспечивающая коммуникацию и включающая набор знаков (словарь) и правила их употребления и интерпретации (грамматика) Источник … Словарь-справочник терминов нормативно-технической документации
ЯЗЫК ПРОГРАММИРОВАНИЯ — это совокупность набора символов (алфавита) системы, правил образования (синтаксис) и истолкования конструкции из символов (семантика) для задания алгоритмов с использованием символов естественного языка. В самом общем виде формальный язык… … Большая политехническая энциклопедия
ЯЗЫК ПРОГРАММИРОВАНИЯ — формальный язык для описания данных (информации) и алгоритма (программы) их обработки на ЭВМ. Основу Я. п. составляют алгоритмические языки. Первыми Я. п. были внутренние машинные языки, представляющие собой системы команд конкретной ЭВМ,… … Большой энциклопедический политехнический словарь
Язык программирования — формальная знаковая система, используемая для связи человека с ЦВМ; предназначена для описания данных (информации) и алгоритмов (программ) их обработки на вычислительной машине. Примеры Я. п. Алгол, Кобол, Фортран, а также машинные языки… … Большая советская энциклопедия
ЯЗЫК — 1) система знаков, служащая средством человеческого общения, мышления и выражения. С помощью языка осуществляется познание мира, в языке объективизируется самосознание личности. Язык является специфическим социальным средством хранения и передачи … Профессиональное образование. Словарь
Язык разметки прогнозного моделирования — Язык разметки для прогнозного моделирования (Predictive Model Markup Language PMML) является языком разметки на основе XML, разработанным Data Mining Group (DMG), и обеспечивающим приложениям способ определения моделей, относящихся к… … Википедия
СОДЕРЖАНИЕ
История
Язык структурированных запросов (SQL)
Многие языки описания данных используют декларативный синтаксис для определения столбцов и типов данных. Однако язык структурированных запросов (SQL) использует набор императивных команд, действие которых заключается в изменении схемы базы данных путем добавления, изменения или удаления определений таблиц или других элементов. Эти операторы можно свободно смешивать с другими операторами SQL, что делает DDL не отдельным языком.
СОЗДАТЬ заявление
Оператор CREATE TABLE
Пример оператора для создания таблицы с именем « сотрудники» с несколькими столбцами:
Некоторые формы CREATE TABLE DDL могут включать в себя конструкции, подобные DML ( языку манипулирования данными ), например синтаксис SQL CREATE TABLE AS SELECT (CTaS).
Заявление DROP
Оператор DROP уничтожает существующую базу данных, таблицу, индекс или представление.
Например, команда для удаления таблицы с именем « сотрудники» выглядит следующим образом:
Оператор ALTER
Оператор ALTER изменяет существующий объект базы данных.
ALTER заявление в SQL изменяет свойства объекта внутренней части реляционной системы управления базами данных (СУБД). Типы объектов, которые можно изменить, зависят от того, какая СУБД используется. Типичное использование:
Например, команда для добавления (а затем удаления) столбца с именем пузырьки для существующей таблицы с именем приемник :