Информационное обеспечение систем управления

5. ЦЕЛОСТНОСТЬ ДАННЫХ Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору {1,2,3,4,5,6,7}. Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений путем проверки заранее определенных правил (не путать с незаконными изменениями и разрушениями, являющимися проблемой безопасности). Современные СУБД имеют встроенные средства для обеспечения целостности данных (так же, как и средств обеспечения безопасности). Выделяют обычно две группы правил целостности – это правила внутренней целостности (целостность сущностей) и правила целостности по ссылкам (внешняя или ссылочная целостность). 5.1. Обеспечение внутренней целостности данных Внутренняя целостность – это поддержка допустимых значений в рамках одного определенного отношения. Будем различать три типа правил, обеспечивающих внутреннюю целостность, а именно: ограничения домена, ограничения первичного ключа и ограничения записи. В ограничения домена будем включать три вида правил – ограничения на неопределенные значения, ограничения типов данных и ограничения поля. Ограничения на неопределенные значения. Основное назначение баз данных состоит в том, чтобы хранить и предоставлять информацию о реалиях предметной области. Для представления этой информации в базе данных используются привычные для программистов типы данных   строковые, численные, логические и т.п. Однако в реальном мире часто встречается ситуация, когда данные неизвестны или не полны. Например, место жительства или дата рождения человека могут быть неизвестны (база данных разыскиваемых преступников). Если вместо неизвестного адреса уместно было бы вводить пустую строку, то что вводить вместо неизвестной даты? Ответ   пустую дату   не вполне удовлетворителен, т.к. простейший запрос "выдать список людей в порядке возрастания дат рождения" даст заведомо неправильных ответ. Для того чтобы обойти проблему неполных или неизвестных данных, в базах данных могут использоваться типы данных, пополненные так называемым NULL-значением. NULL   это, собственно, не значение, а некий маркер, показывающий, что значение неизвестно. Таким образом, в ситуации, когда возможно появление неизвестных или неполных данных, разработчик имеет выбор из двух вариантов. Первый вариант состоит в том, чтобы ограничиться использованием обычных типов данных и не использовать NULL, а вместо неизвестных данных вводить либо нулевые значения, либо значения специального вида   например, договориться, что строка "АДРЕС НЕИЗВЕСТЕН" и есть те данные, которые нужно вводить вместо неизвестного адреса. В любом случае на пользователя (или на разработчика) ложится ответственность на правильную трактовку таких данных. В частности, может потребоваться написание специального программного кода, который в нужных случаях "вылавливал" бы такие данные. Проблемы, возникающие при этом очевидны   не все данные становятся равноправны, требуется дополнительный программный код, "отслеживающий" эту неравноправность, в результате чего усложняется разработка и сопровождение приложений. Второй вариант состоит в использовании NULL вместо неизвестных данных. За кажущейся естественностью такого подхода скрываются менее очевидные и более глубокие проблемы. Наиболее бросающейся в глаза проблемой является необходимость использования трехзначной логики при оперировании с данными, которые могут содержать NULL-значения. В этом случае при неаккуратном формулировании запросов, даже самые естественные запросы могут давать неправильные ответы. Есть более фундаментальные проблемы, связанные с теоретическим обоснованием корректности введения NULL, например, непонятно вообще, входят ли оно в домены или нет. Практически все реализации современных реляционных СУБД позволяют использовать NULL-значения, несмотря на их недостаточную теоретическую обоснованность. В конструкторе DBF-файлов VFP для каждого поля можно задать NULL   отсутствие явно присвоенного значения (см. ниже рис. 5.1). NULL не эквивалентно нулю или пропуску. О значении NULL нельзя говорить, что оно больше, меньше, не равно или эквивалентно какому-либо другому значению, включая другое значение NULL. Ограничения типов данных. Данные, записываемые в ячейки поля, не могут быть абсолютно произвольными. С каждым полем связано множество значений, такое, что только элементы этого множества могут записываться в соответствующее поле. Множество допустимых значений поля называют доменом или словарём данного поля. Определение словаря любого поля производится путём наложения условий на данные, записываемые в поле. Эти условия могут быть формализуемыми, которые можно задать в виде, например, логических соотношений, реализуемых компьютером, и не формализуемым, которые не могут быть реализованы программно. Главным из формализуемых ограничений для всех полей является тип данных, которые могут храниться в ячейках каждого определенного поля. Типы данных СУБД VFP анализируются в следующем подразделе. Ограничение поля или правила контроля значений для определенного поля. Этим правилом является логическое выражение или логическая функция пользователя. Проверка значения поля производится при любом его изменения в момент выхода за пределы поля. Такие проверки реализованы в команде Browse, при выполнении команды REPLACE и т.п. Если логическое выражение имеет значение .T., то изменение поля допускается, если   .F., то нет, и при этом выдается заданное сообщение. Проверка не требует написания каких либо дополнительных процедур. Поэтому она называется декларативной, в отличие от процедурной, основанной на программных процедурах и функциях. Проверка реализуется при выходе из поля, если его значение было изменено. Просмотр поля не вызывает проверки. Проверка реализуется не только в экранных формах, но и при выполнении команд: APPEND, BROWSE, CHANGE, DELET, EDIT, INSERT, REPLACE, UPDATE. Например, контроль поля с именем PT, используемого для хранения часового тарифа, который должен принадлежать отрезку [1080], можно обеспечить следующим логическим выражениям PT10. AND. PT80, и в случае значения .F., выдать сообщение “Почасовая оплата должна принадлежать интервалу 10 и 80”. Другой пример   контроль поля типа даты с именем DS, в котором не допускается значение меньшее текущей даты (как при совершении сделки), можно обеспечить выражениям DS DATE(), и сообщениям “Вводимая дата не должна быть ранее ”+DTOC(DATE()). Воспользоваться возможностями контроля поля можно в конструкторе таблиц (Table Designer, см. рис. 5.1); на закладке Fields которого можно задать требуемые логические выражения. При этом система позволяет применить построитель выражений с большим набором встроенных функций. Ограничения первичного ключа. Данный тип ограничений часто называют целостностью сущностей. Ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Однозначность или уникальность – это недопустимость двух одинаковых значений. Каждая сущность обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ. Первичные ключи отношения фактически служат идентификаторами объектов предметной области (т.е. предназначены для различения объектов). Значения этих идентификаторов не могут содержать неизвестные значения. Действительно, если бы идентификаторы могли содержать NULL-значения, то мы не могли бы дать ответ "да" или "нет" на вопрос, совпадают или нет два объекта. Этот факт определяет правило целостности сущностей. Поля отношения, входящие в состав первичного ключа не могут принимать NULL-значений. В ранних версиях FoxPro данное ограничение системой не поддерживалось. Оно было не формализуемым, в VFP такая поддержка возможна – на закладке Indexes конструктора таблиц можно определить индекс с именем поля в качестве индексного выражения и назначить ему тип Primary. В этом случае система обеспечит требования ограничений первичного ключа. Ограничения записи. На закладке Table конструктора таблиц можно задать дополнительные ограничительные свойства для записи в целом. В пределах каждой записи таблицы значения полей в соответствии с реалиями предметной области могут быть взаимозависимыми. Взаимозависимость значений полей обеспечивается правилами контроля записи. Правила в виде логических выражений могут включать имена более чем одного поля в отличии от правил контроля полей. Проверка производится при попытке перехода на другую запись после любого изменения в текущей записи. Если нет изменений, то нет проверки. Например, если в таблице есть поле даты приема на работу с именем DP и поле даты рождения с именем DR, то одно из правил приема на работу (совершенолетие) можно контролировать, используя выражение (DP-DR)/365>=18 , и текст сообщения “Возраст < 18 лет”, который отобразится, если выражение примет значение .F. Если правило контроля поля или записи сложное и не укладывается в одно выражение, то его можно оформить в виде функции пользователя и записать как хранимую процедуру DBC-файла. Текст функции можно ввести, выбрав пункты Database/Edit/Stored procedure. Изменить текст процедуры можно командой Modify Procedure в командном окне при открытом DBC-файле. Функция должна возвращать результат логического типа. Если он .F., то VFP не позволит переместить указатель на другую запись и не сохранит сделанные изменение, отображая при этом сообщение, заданное в поле Validation text. В тексте функции нельзя перемещать указатель записи, т.к. это приведет к рекурсивному вызову функции; так же нельзя изменять значение любого поля, закрывать рабочие области или открывать в них новые файлы. При отключении DBF-файла от DBC-файла процедуры остаются в DBC-файле, но они уже не будут связанны с данными DBF-файлами. Рассмотрим ряд дополнительных возможностей DBF-файлов, которые возникают в случае подключения его к DBС-файлу. Эти возможности обеспечиваются дополнительной информацией хранимой для каждого DBF-файла в DBС-файле, точнее в DBС-файле и двух вспомогательных DCT и DCX-файлах. Воспользоваться этими возможностями можно в конструкторе таблиц (Table Designer); на закладке Fields которого можно задать следующие параметры. 1. Параметры отображения поля: формат отображения, маску ввода и заголовок поля. Например, маски ввода для телефонного номера 99-99-99; заголовок для поля pol1 “Дети сотрудников”. 2. Значение поля по умолчанию. Задается выражение для выбранного поля, значение которого будет автоматически заноситься при добавлении записи. Например, если добавляются записи о продажах и чаще всего продают один товар, то в поле имени товара есть смысл внести наименование этого товара. 3. Заголовок поля. При отображении в Browse и Grad столбец, соответствующий полю будет иметь заданный заголовок. 4. Для каждого поля есть возможность задать текст комментария, отражающий смысловое назначение поля. 5.2. Типы данных в VFP Все типы данных в VFP по критерию “длина” делятся на три класса: данные с длиной задаваемой разработчиком; данные с фиксированной длиной; данные с переменной длиной. Рассмотрим каждый из этих классов. Типы с задаваемой длиной. К данному классу относятся типы для представления символьных и числовых данных. Символьные данные описываются типом Character. Условная запись для него   Сх, где х[1,254]. В полях этого типа можно хранить от 1 до 254 символов, включающих буквы, числа, пробелы и знаки препинания. Поля, требующие больше 254 символов, должны определяться как поля типа Memo. Поля типа Character имеют фиксированный задаваемый размер. Если для поля с именем Address вы установите размер в 35 символов, то оно в каждой записи будет занимать ровно 35 символов, даже если значение поля Address равно 18 (Тихоокеанская, 136). Казалось бы, стоит ли переживать из-за нескольких неиспользованных символов, но 5-символьная разница в длине поля для файла с 300 тыс. записей составляет более 1.4 Мбайт. С другой стороны, если в поле Address вы попытаетесь поместить текст длиной более 35 символов, VFP сохранит только первые 35 и отбросит остальные. Поля типа Character можно также использовать для хранения значений, состоящих полностью из чисел. Например, в виде символьных полей следует хранить такие данные, как почтовые индексы, номера телефонов и даже идентификационные номера заказчиков, причем на это есть свои причины. Во-первых, в числовых полях отсекаются ведущие нули, т.е. если требуется сохранить почтовый индекс в виде 02003, то при использовании числового типа поля VFP сохранит это значение как 2003. Во-вторых, телефонный номер следует хранить в определенном формате, например (412)21-88-53. Наконец, для формирования индекса может понадобиться комбинация двух полей: например, полей, содержащих код поставщика и код товара. Обычно для образования одиночного индексного выражения можно объединять поля только путем конкатенации символьных строк. Чтобы при определении поля легче было сделать выбор между типами Character и Numeric, следует подумать о том, не придется ли вам выполнять вычисления с этим полем. А дальше все очень просто. При положительном ответе определите поле как Numeric, а при отрицательном   как Character. Числовые данные с фиксированной точкой описываются типом Numeric. Условная запись на схемах   Nх или Nx,y, где x[1,20] и y[1,19]. Числовые данные с плавающей точкой имеют тип Float;  Fx,y, где x[1,20] y[0,19]. Кроме того, имеется тип Double для данных с двойной точностью (Dx,y). Типы с фиксированной длиной. Тип поля Currency предназначен для хранения значений, выражающих денежные суммы. Максимальное значение, которое может принимать поле этого типа, соответствует числу, немногим превышающему $922 триллиона. По умолчанию для значений полей типа Currency отводится четыре десятичных знака и требуется восемь байтов памяти. Типы полей Date и DateTime схожи в том, что они оба используются для хранения дат в формате yyyy.mm.dd, причем для этого им требуется восемь байт, независимо от того, какое значение задано в команде set century on или off. Поле типа DateTime использует сжатый формат хранения времени в виде hhmmss (ЧЧММСС), где ЧЧ •имеет 24-часовое представление. Если преобразовать поле типа Date в поле типа DateTime, то по умолчанию время будет отображаться в формате 12:00:00. В VFP предусмотрен диапазон дат от 01/01/1   (1 января 1 года н.э.) до 12/31/9999 (31 декабря 9999года), а диапазон значений времени от 12:00:00 до 11:59:59. Используя функцию datetime(), в записи, содержащей поле типа DateTime, можно зафиксировать текущие значения даты и времени. Для увеличения на один день даты, хранящейся в поле типа Date, необходимо к его значению добавить 1. Но чтобы увеличить на один день дату, хранящуюся в поле типа DateTime, необходимо добавить к его значению число 86400, так как в сутках содержится ровно 86400 секунд. В поле типа Logical хранится двоичная информация в виде .Т. или .F.. Это поле предназначено для запоминания данных, имеющих только два возможных значения. К такому типу, например, можно отнести данные, которые выражаются следующим образом: "подлежит /не подлежит налогообложению", "мужчина/женщина", "отгружено/заказ не выполнен". Поле типа Logical часто служит источником информации для флажков опций. Типы с переменной длиной. Поля Memo (поля примечаний) позволяют хранить большие символьные строки длиной более 254 символов. Для хранения каждой записи предоставляется переменный (нефиксированный) объем памяти, зависящий от размера блока. Блок имеет фиксированную в пределах всей таблицы длину. По умолчанию VFP использует блоки размером 64 байт. Это означает, что каждый фрагмент текста, состоящий из 64 символов, требует дополнительного блока. Например, для строки длиной 72 байт потребуется два 64-символьных блока (причем во втором блоке будет занято лишь 8 байт). Из 64 байт в каждом блоке Memo-поля 8 байт выделяется для двух 4-байтовых указателей. Эти указатели используются в VFP для отыскания предыдущего или последующего блоков. Таким образом, строго говоря, с точки зрения пользователя, блок Memo-поля имеет только 56 байт. Размер блока можно изменить с помощью команды SET BLOCKSIZE, которая устанавливает число байтов в диапазоне от 33 до 511. Для определения блоков большего размера используйте целое число в диапазоне 1   32, которое означает, что длина блока определяется произведением заданного числа и числа 512. В VFP можно задать нулевой размер блока, что заставит систему выделять память побайтово и тем самым не допустит напрасных потерь памяти. Однако в этом случае пострадает быстродействие системы, чего не происходит при использовании блоков заданных размеров. Размер блока должен быть задан командой SET BLOCKSIZE перед добавлением первой записи с memo-полем. При добавлении первой записи VFP заносит текущий размер блока в memo-файл. Изменяя размер блока уже существующего memo-файла, необходимо перезаписать каждое memo-поле. Однако, независимо от размера блока, не забудьте, что в первом блоке резервируется восемь байтов для указателей. Почему столько беспокойства относительно размера блока? Чем больше размер блока, тем больше потраченной памяти при хранении разных по длине memo-полей. С другой стороны, чем больше блоков используется при хранении memo-полей, тем менее эффективен процесс их выборки. Поэтому размер блока лучше определять, исходя из наиболее вероятной длины поля. VFP хранит memo-поля в файле с расширением FPT, отдельно от DBF-файла. Независимо от количества memo-полей в таблице, VFP хранит их в одном FPT-файле. А если в вашей таблице используются и поля типа General, VFP хранит их в том же самом файле вместе с memo-полями. В DBF-файле предусмотрены специальные указатели, которые отслеживают принадлежность memo-информации каждой записи и полю. Поскольку в указателях memo-полей задан только один путь   из DBF- в FPT-файл, нужно следить за тем, чтобы эти DBF- и FPT-файлы никогда не отделялись друг от друга. Как такое может случиться? Допустим, у вас есть таблица с memo-полем на двух или нескольких машинах. При копировании DBF-файла с одной машины на другую без FPT-файла (например, по халатности) копия этого файла не будет синхронизирована с текущим FPT-файлом, оставшимся на другой машине. Если это случится и вы начнете добавлять записи, то вскоре обнаружится, что текст memo-полей больше не соответствует "своим" записям. Эту проблему практически невозможно устранить без установки вручную указателей, определяющих путь из DBF- в FPT-файл. Для выполнения этой очень сложной задачи на рынке программных продуктов предлагаются инструментальные средства, созданные независимыми производителями. Не стоит волноваться относительно записей с пустыми значениями memo-полей, так как VFP нe резервирует для них дополнительную память в memo-файле. Однако каждое memo-поле в каждой записи требует наличия четырехбайтового указателя в DBF-файле, даже если это поле пустое. Приведены типичные случаи использования memo-полей: символьные поля, которые лишь иногда заполняются; очень большие по длине символьные поля или поля, длина которых не может быть заранее предсказана; текстовые файлы с резюме, деловыми письмами и архивами версий программ. Рис. 5.1. Типы данных в VFP 8.0 Чаще всего поле типа General (общий) используется для хранения графических изображений и представляет собой специализированное Memo-поле. VFP хранит поле типа General в том же FPT-файле, в котором хранятся и другие Memo-поля таблицы, но это не дает вам право использовать его таким же образом. Поле типа General первоначально предназначалось для хранения ссылок на связанные объекты OLE. Кроме рассмотренных типов VFP поддерживает ряд других типов. Полное множество типов, которое поддерживает СУБД VFP 8.0 , иллюстрируется формой, приведенной на рис. 5.1. Эта форма является интерфейсом Конструктора таблиц, который входит в состав визуальных средств разработки АИС. 5.3. Обеспечение ссылочная целостность данных Различные объекты предметной области, информация о которых хранится в базе данных, всегда взаимосвязаны друг с другом. Например, накладная на поставку товара содержит список товаров с количествами и ценами, сотрудник предприятия имеет детей, числится в подразделении и т.д. Термины "содержит", "имеет", "числится" отражают взаимосвязи между понятиями "накладная" и "список товаров", "сотрудник" и "дети", "сотрудник" и "подразделение". Такие взаимосвязи отражаются в реляционных базах данных при помощи внешних ключей, связывающих два и более отношений. Для практической поддержки связей оба отношения должны содержать наборы атрибутов (в простейшем случае   один атрибут), по которым эта связь осуществляется. В первом отношении это первичный ключ (PRIMARY KEY), который однозначно определяет кортежи этого отношения. Во втором   для моделирования связи должен присутствовать атрибут, соответствующий первичному ключу первого отношения. Однако здесь этот атрибут уже не является первичным ключом. Он определяет множество кортежей, которые связаны с единственным кортежем первого отношения. Данный атрибут во втором (подчиненном) отношении принято называть внешним ключом (FOREIGN KEY). Например, рассмотрим ситуацию, когда надо описать карьеру некоторого индивидуума. Каждый человек в своей трудовой деятельности сменяет несколько мест работы в разных организациях, где он работает в разных должностях. Один из вариантов отражения данного факта   создать два отношения: одно для описания всех работающих людей, а другое для моделирования записей в их трудовых книжках (рис. 5.2). В приведенном примере первичным ключом PRIMARY KEY отношения

Похожие:

	«Учебно-методический комплекс дисциплины «Информационное обеспечение систем управления»		Пояснительная записка «Современная организация и технология документационного обеспечения управления». Он связан с курсами «Документоведение», «Информационное...
	Исследование систем управления процесс определения организационной... Место исследований систем управления в комплексе дисциплин по теории и практке управления		Программное обеспечение для отладки систем управления упругими объектами Целью данной работы является разработка программного обеспечения для лабораторного стенда для изучения систем управления упругими...
	Рабочая программа дисциплины «Информационное обеспечение, базы данных» Факультет информационных систем и технологий Кафедра Прикладной математики и вычислительной техники		Учебная программа по дисциплине " информационное обеспечение управления " Изучение теоретических, методических и практических вопросов разработки, внедрения и совершенствования информационного обеспечения...
	Российской Федерации Самарский государственный архитектурно-строительный... Информационные системы” являются информационные системы и сети, их математическое, информационное и программное обеспечение, способы...		Рабочая программа дисциплины «Архитектура ЭВМ и вычислительных систем»... «Автоматизированные системы обработки информации и управления» (по отраслям) и 230105 «Программное обеспечение вычислительной техники...
	Исследование систем управления Целью работы является рассмотрение частных методов исследования систем управления, а именно эксперимент, наблюдение и опрос		Примерная тематика рефератов по курсу «Исследование систем управления» Современный менеджмент и необходимость исследования систем управления социально-экономической организацией
	Организационно-правовое обеспечение правовой деятельности Информационное обеспечение организации и проведения внеучебной работы		Исследование систем управления Специальности: «Менеджмент организации» «Исследование систем управления» является ведущей,в учебном процессе среди смежных дисциплин
	Реферат по дисциплине "Избирательное право" тема: Информационное... Информационное обеспечение выборов. Правовое регулирование предвыборной агитации в РФ		Информационное обеспечение управления В настоящее время классификационные схемы (классификаторы) строятся не только на основе соподчинения понятий (метод иерархии), но...
	Курсовая работа По дисциплине «Базы данных» Программное обеспечение для создания систем управления базами данных		Рабочая программа учебной дисциплины «исследование систем управления» Студенты научатся методам планирования эксперимента и организации исследования систем управления и научатся использовать приобретенные...