Cтраница 3
Различные документы этапа редактирования оказывают существенную помощь в разрешении возникающих при проектировании проблем и в обнаружении несогласованностей, касающихся использования, формата и смысла элементов данных, определенных в различных локальных представлениях. Алфавитный список имен данных, содержащийся в документе Описание элементов данных с указанием их использования, список Ключевые слова в контексте, содержащий имена элементов данных и их квалификаторы, и список Пересекающиеся атрибуты помогают конструктору обнаружить синонимы и омонимы. С помощью отчета, содержащего сведения о несогласованных ассоциациях, также можно обнаружить омонимы и определить, в каких случаях нужно переопределять требования к данным. Отредактированные локальные представления и отчет Описание элементов данных с указанием их использования помогают определить различное использование одного и того же элемента данных, неправильные форматы и уточнить смысл предполагаемых для хранения элементов данных. После завершения стандартизации имен автоматизированная процедура редактирования осуществляет сравнение имен элементов данных в различных локальных представлениях со списком стандартных имен и может зафиксировать обнаруженные противоречия, передавая эти сведения проектировщику. Для выполнения таких действий необходимо наличие итеративной процедуры редактирования, причем ее автоматизация обеспечивает намного более удобную форму ее выполнения. [31]
Отчет содержит список атрибутов, имеющих больше одного ключа. Такие атрибуты и их ключи могут представлять избыточные или пересекающиеся данные. Они также могут быть результатом несогласованности имен элементов данных. Этот документ упоминался выше при обсуждении процесса редактирования, и здесь о нем говорится потому, что его информация может быть полезна при выборе различных структурных решений. [32]
Назначение процедур проектирования заключается в том, чтобы собрать и проанализировать требования к данным, обусловленные функциями обработки, интерпретировать их с целью получения эффективной структуры базы данных и документировать как сам процесс проектирования, так и результаты его выполнения. Они ориентированы в основном на сбор и анализ требований к данным и их редактирование для обеспечения согласованности в использовании данных и стандартизации имен элементов данных. Процессы логического и физического проектирования описаны в книге полностью. Кроме того, описаны возможное взаимодействие между процедурами проектирования и словарной системой и интерактивный язык взаимодействия проектировщика баз данных с процедурами проектирования. [33]
![]() |
Деревья базы данных как расширение дерева определения. [34] |
Описание элемента данных специфицирует уникальное имя элемента в дереве определения, тип данных, ссылку на повторяющуюся группу, которой принадлежит элемент, а также необязательное указание на то, что данный элемент является ключом. Термин ключ употребляется в S2K в ином смысле, чем в гл. Иерархический характер структуры отображается соответствующим расположением строк текста, как это показано на рис. 7.2.5 для описания схемы медицинской базы данных. Если имя элемента данных само пс себе не является уникальным, то ему предшествует имя типа записи. [35]
Плохо нарисованная схема может скорее сбить с толку, чем дать ясное представление о данных. На рис. 6.6 приведена схема, которая используется во многих современных публикациях. В ней есть несколько неточностей. Во-первых, имя некоторой части схемы представлено как блок, идентичный блоку, содержащему имя элемента данных. ЗАРПЛАТА и ПРОФЕССИЯ, например, расположены рядом в идентичных блоках, в то время как ЗАРПЛАТА представляет собой элемент данных, а ПРОФЕССИЯ - нет. ПРОФЕССИЯ является именем группы элементов данных, содержащей КОД и ДОЛЖНОСТЬ. Во-вторых, на диаграмме не отражено различие между атрибутами и объектами. Блок ДАТА-РОЖДЕНИЯ находится в группе блоков, содержащей блок РЕБЕНОК. [36]
Имена ИМЯ и ИМЯ-ИГРОКА вызывают такие же вопросы. Анализируя имена элементов данных НОМЕР-НА-МАЙКЕ и НОМЕР-ИГРОКА, можно предположить, что они относятся к одному и тому же элементу данных. Просматривая список, встречаем имя ИГРОК. Имя элемента данных ПОЗИЦИЯ предполагает три возможных толкования: 1) имеет ли в виду конечный пользователь ту позицию, которую занимает игрок в настоящее время, или 2) это те позиции, на которых он может играть, или, наконец, 3) те позиции, на которых он когда-то играл. [37]
Различные документы этапа редактирования оказывают существенную помощь в разрешении возникающих при проектировании проблем и в обнаружении несогласованностей, касающихся использования, формата и смысла элементов данных, определенных в различных локальных представлениях. Алфавитный список имен данных, содержащийся в документе Описание элементов данных с указанием их использования, список Ключевые слова в контексте, содержащий имена элементов данных и их квалификаторы, и список Пересекающиеся атрибуты помогают конструктору обнаружить синонимы и омонимы. С помощью отчета, содержащего сведения о несогласованных ассоциациях, также можно обнаружить омонимы и определить, в каких случаях нужно переопределять требования к данным. Отредактированные локальные представления и отчет Описание элементов данных с указанием их использования помогают определить различное использование одного и того же элемента данных, неправильные форматы и уточнить смысл предполагаемых для хранения элементов данных. После завершения стандартизации имен автоматизированная процедура редактирования осуществляет сравнение имен элементов данных в различных локальных представлениях со списком стандартных имен и может зафиксировать обнаруженные противоречия, передавая эти сведения проектировщику. Для выполнения таких действий необходимо наличие итеративной процедуры редактирования, причем ее автоматизация обеспечивает намного более удобную форму ее выполнения. [38]
До сих пор мы рассматривали логические структуры, построенные на основе определения отношений между элементами множества данных, а также отображения в физические структуры памяти, определяемые адресными функциями. Однако для прикладного программиста было Оы слишком долго и утомительно программировать средства управления базой данных в каждой своей программе, использующей эту базу. Поэтому универсальные системы управления базами данных ( СУБД) часто поставляются как часть общего программного обеспечения, так же как, например, различные компиляторы. СУБД обеспечивает хранение и обновление данных, а также доступ к ним нескольким программам. Для достижения такой интеграции данных определяется формат данных; это определение данных хранится, и к нему имеется доступ из СУБД. Вообще говоря, в определении данных устанавливается имя элемента данных, его свойства ( например, тип), а также взаимосвязи с другими элементами базы данных. Данные могут использоваться совместно многими пользователями, поэтому чрезвычайно важно обеспечить целостность хранимых данных с течением времени, а также защиту данных от несанкциониоованного доступа. [39]
До сих пор мы рассматривали логические структуры, построенные на основе определения отношений между элементами множества данных, а также отображения в физические структуры памяти, определяемые адресными функциями. Однако для прикладного программиста было оы слишком долго и утомительно программировать средства управления базой данных в каждой своей программе, использующей эту базу. Поэтому универсальные системы управления базами данных ( СУБД) часто поставляются как часть общего программного обеспечения, так же как, например, различные компиляторы. СУБД обеспечивает хранение и обновление данных, а также доступ к ним нескольким программам. Для достижения такой интеграции данных определяется формат данных; это определение данных хранится, и к нему имеется доступ из СУБД. Вообще говоря, в определении данных устанавливается имя элемента данных, его свойства ( например, тип), а также взаимосвязи с другими элементами базы данных. Данные могут использоваться совместно многими пользователями, поэтому чрезвычайно важно обеспечить целостность хранимых данных с течением времени, а также защиту данных от несанкционированного доступа. [40]