Компьютерная наука

Кому нужна программа Автокад?

Рейтинг пользователей: / 1
ХудшийЛучший 

В этой статье размещены программы Autocad некоторых версий. Их работоспособность проверена. Кроме этого, последние версии данных программ идут в двух вариантах – 32 и 64 битных.

Autocad 2012

Программа Autocad 2012 похожа на программу autocad 2014, купить которую можно в специализированном магазине. Она является лидером среди 2D и 3Dпроектирования. За счет 3Dмоделирования ускоряются проектные работы, а также выпуск документации. Также доступны тысячи настроек, за счет чего можно удовлетворить потребности самых капризных клиентов. Новые возможности данного продукта называют прорывом, который сможет порадовать миллионы пользователей этой программы. Автокад 2012 стал параметрическим. За счет этого сокращается время на изменение в проектах. Появились инструменты работы с различными формами, поэтому стало возможно создать и проанализировать сложные объекты. Кроме этого, есть 3D печать, другими словами, стало проще получать физические прототипы. Еще усовершенствована работа с PDF файлами. Их можно применять в качестве подложки и улучшено качество формата PDF. Это позволяет упрощать обмен данными между заинтересованными в проекте сторонами.

Autocad 2011

Сначала хочется сказать, что программу autocad 2012 можно как и autocad 2014 купить в специализированном магазине. Данный продукт решает сложные проектные проблемы. С помощью средств создания произвольных форм можно смоделировать самые разные тела и поверхности. Время на проверку проектов сокращено, а параметрические чертежи всю необходимую информацию держат под рукой. Проектные идеи этого продукта можно визуалировать в формат PDF и реализовать в макет, который получается при помощи 3D печати. Идеи еще никогда не превращались в реальность настолько быстро. Появилась возможность задать зависимость между объектами. Например, параллельные линии всегда остаются параллельными, а концентрическая окружность всегда имеет общий центр. Теперь можно воплотить любые идеи в проект. Для того чтобы создавать сложные формы можно просто перемещать грани, вершины и ребра.

Autocad 2010

Хочется заметить, что autocad 2010 по своим возможностям напоминает autocad 2014, цена которого достаточно высокая. Новые возможности данного продукта называют технологическим прорывом, и она радует миллионы своих пользователей по всему миру. Программа стала параметрической, и теперь любые изменения поддерживают взаимосвязи.

Autocad 2009

На Autocad 2009, если сравнивать его с autocad 2014, цена разная, но все, же доступная для всех желающих. Следует заметить, что данная программа предназначена для автоматизированного проектирования и помогает в создании машиностроительных, строительных и архитектурных работ. Данная программа повышает эффективность работы за счет улучшенного настраиваемого интерфейса.

 

ACDSee Pro – это продуктивный инструмент для профессиональной обработки файлов

Рейтинг пользователей: / 3
ХудшийЛучший 

ACDSee осуществляет просмотр и редактирование изображений абсолютно бесплатно

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

Наличие большого количества инструментов позволит превратить обычный графический файл в шедевр. Устранение недостатков осуществляется всего за несколько кликов.

Редактор поможет Вам упорядочить фотографии на своем ПК, и создать структурированную галерею.

Дубликаты изображений программа находит самостоятельно не только по названию, а и по содержанию. Это поможет Вам очистить компьютер от лишних файлов.

Редактирование в ACDSee:

Вы можете значительно ускорить темпы своей работы, используя пакетную обработку, доступную в программе. Также она позволяет работать с фотографиями высокого уровня четкости. Благодаря программе можно редактировать, просматривать и опубликовывать изображения. Любой профессионал найдет для себя нужный ему пакет опций. Можно работать с мета-данными, осуществлять обработку в разных пиксельных режимах, и пополнять резервные данные незаметно. Все точно оценят новый вид Ваших фото.

Рабочее пространство программы:

Используя функцию импорта фотографий, Вы можете приступать к работе с материалами, с любого устройства хранения данных. Изображения можно сортировать, сравнивать и подбирать для них рамку. Любой снимок можно просмотреть в полноэкранном режиме. Есть возможность сравнить несколько похожих снимков для выбора самого удачного кадра.

Фотографии можно каталогизировать, а также восстанавливать, используя гибкую систему, которая создавалась для удобства любого пользователя. Ваша фотоколлекция всегда будет под рукой.

Приложение дает пользователям мощные инструменты для работы с файлами формата RAW, именно в таком формате большинство фотоаппаратов сохраняют изображения. Теперь Вы можете сразу после создания снимка заняться его обработкой.

Интерфейс ACDSee простой и удобный в использовании. Вы можете настроить горячие клавиши на свое усмотрение. Возможности программы радуют своими расширенными функциями. Это Удобный просмотрщик графических файлов, а также аудио и видео. Он поддерживает более ста разных графических форматов. С его помощью можно архивировать и восстанавливать медиафайлы, пересматривать фотографии в режиме слайд-шоу.

Скачать ACDSee бесплатно и без затруднений, Вы сможете с официального сайта, где можно найти русскоязычную версию приложения.

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

Сразу после установки, программа будет готова к использованию. Преимуществом будет поддержка форматов RAW для Nikon, Canon, Olympus и Fuji.

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

{jcomments on}

 

Физическое проектирование базы данных

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

Как правило, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных.

В случае реляционной модели данных под этим подразумевается следующее:

  • создание набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;
  • определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;
  • разработка средств защиты создаваемой системы.
  • Перенос глобальной логической модели данных в среду целевой СУБД.
  • Проектирование основных отношений.
  • Разработка способов получения производных данных.
  • Реализация ограничений предметной области.
  • Проектирование физического представления базы данных.
  • Анализ транзакций.
  • Выбор файловой структуры.
  • Определение индексов.
  • Определение требований к дисковой памяти.
  • Проектирование пользовательских представлений.
  • Разработка механизмов защиты.
  • Обоснование необходимости введения контролируемой избыточности.
  • Текущий контроль и настройка операционной системы.

Этапы концептуального и логического проектирования больших систем следует отделять от этапов физического проектирования. На это есть несколько причин.

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

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

Этапы методологии физического проектирования баз данных:

 

  • Перенос глобальной логической модели данных в среду целевой СУБД.
  • Проектирование основных отношений.
  • Разработка способов получения производных данных.
  • Реализация ограничений предметной области.
  • Проектирование физического представления базы данных.
  • Анализ транзакций.
  • Выбор файловой структуры.
  • Определение индексов.
  • Определение требований к дисковой памяти.
  • Проектирование пользовательских представлений.
  • Разработка механизмов защиты.
  • Обоснование необходимости введения контролируемой избыточности.
  • Текущий контроль и настройка операционной системы
 

Логическое проектирование базы данных

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

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

Если концептуальная модель данных не зависит от любых физических аспектов реализации, то логическая модель данных создается на основе выбранной модели организации данных целевой СУБД. Иначе говоря, на этом этапе уже должно быть известно, какая СУБД будет использоваться в качестве целевой — реляционная, сетевая, иерархическая или объектно-ориентированная. Однако на этом этапе игнорируются все остальные характеристики выбранной СУБД, например, любые особенности физической организации ее структур хранения данных и построения индексов.

В процессе разработки логическая модель данных постоянно тестируется и проверяется на соответствие требованиям пользователей.

Созданная логическая модель данных является источником информации для этапа физического проектирования и обеспечивает разработчика физической базы данных средствами поиска компромиссов, необходимых для достижения поставленных целей, что очень важно для эффективного проектирования. Логическая модель данных играет также важную роль на этапе эксплуатации и сопровождения уже готовой системы. При правильно организованном сопровождении поддерживаемая в актуальном состоянии модель данных позволяет точно и наглядно представить любые вносимые в базу данных изменения, а также оценить их влияние на прикладные программы и использование данных, уже имеющихся в базе. Физическое проектирование базы данных - процесс подготовки описания реализации базы данных на вторичных запоминающих устройствах; на этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты.

 

Концептуальное проектирование базы данных

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

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

 

Нормальные формы: 1НФ, 2НФ, 3НФ, нормальная форма Бойса-Кодда, 4НФ, 5НФ

Первая нормальная форма (1NF)

Переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов.

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

Вторая нормальная форма (2NF)

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

Третья нормальная форма (3NF)

Основная статья: Третья нормальная форма

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

Нормальная форма Бойса — Кодда (BCNF)

Переменная отношения находится в нормальной форме Бойса — Кодда (иначе — в усиленной третьей нормальной форме) тогда и только тогда, когда каждая ее нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ.

Четвёртая нормальная форма (4NF)

Переменная отношения находится в четвёртой нормальной форме, если она находится в нормальной форме Бойса — Кодда и не содержит нетривиальных многозначных зависимостей.

Пятая нормальная форма (5NF)

Переменная отношения находится в пятой нормальной форме (иначе — в проекционно-соединительной нормальной форме) тогда и только тогда, когда каждая нетривиальная зависимость соединения в ней определяется потенциальным ключом (ключами) этого отношения.

 

Функциональные зависимости: тривиальные и нетривиальные зависимости; замыкание множества зависимостей; правила вывода Армстронга; неприводимое множество зависимостей

Рейтинг пользователей: / 3
ХудшийЛучший 

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

{   S#,    Р#   }  → S#

Действительно, функциональная зависимость является тривиальной тогда и  только тогда, когда правая часть ее символической записи является подмножеством (не обязательно строгим подмножеством) левой части.

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

Множество всех функциональных зависимостей, которые следуют из заданного множества функциональных зависимостей s, называется замыканием множества s и обозначается символом S+ (необходимо учитывать то, что оно не имеет ничего общего с понятием замыкания, которое рассматривается в реляционной алгебре). Из приведенного определения следует, что для решения сформулированной задачи необходимо найти алгоритм вычисления S+  на основе S. Первая попытка решить эту проблему была предпринята в статье Армстронга (Armstrong) [11.2], в которой автор предложил набор правил вывода новых функциональных зависимостей на основе заданных (эти правила также часто называют аксиомами  Армстронга).Эти правила вывода могут формулироваться разными способами, из которых самым простым является следующий. Пусть А,ви С — произвольные подмножества множества атрибутов заданной переменной отношения R. Условимся также, что символическая запись АВ означает объединение множеств А И В. Тогда правила вывода определяются следующим образом.

1.           Правило рефлексивности. Если множествовявляется подмножеством множества А,

ТО А  →   В.

2.           Правило дополнения. Если А → B, то АС → ВС.

3.           Правило транзитивности. Если А → B и B→C, то А → С.

Каждое из этих трех правил может быть непосредственно доказано на основе определения функциональной зависимости (безусловно, первое из них — это просто само определение тривиальной зависимости). Более того, эти правила являются полными в том смысле, что для заданного множества  функциональных  зависимостей s минимальный набор функциональных зависимостей, которые подразумевают все зависимости из множества S, может быть выведен из ФЗ множества s на основе только этих правил. Они являются также непротиворечивыми, поскольку с их помощью не могут быть выведены никакие дополнительные функциональные зависимости (т.е. зависимости,  которые не обусловлены функциональными зависимостями множества S). Иначе говоря, эти правила могут использоваться для получения замыкания S+.

В целях упрощения задачи практического вычисления замыкания S+, из трех приведенных выше правил можно вывести несколько дополнительных правил. (В дальнейшем предполагается, что D — это еще одно произвольное подмножество множества атрибутов R.)

4.           Правило самоопределения. А → А.

5.           Правило декомпозиции. Если А → ВС, то А → Bи A → C.

6.           Правило объединения. Если А → В И А → С, то А → ВС.

7.           Правило композиции.  Если А → B и С → D, то АС → BD.

Кроме того, Дарвен (Darwen) в своей работе [11.7] доказал следующее правило,  которое он назвалобщей теоремой объединения.

8.          Если  А→  B  и C    →  D,  то  А   ∪   ( С В )   →  BD  (здесь   символ   " ∪ " обозначает                                                                                 операцию объединения множеств, а символ "-" — операцию разности множеств).

Множество функциональных зависимостей называется неприводимым  тогда и только тогда, когда оно обладает всеми тремя перечисленными ниже свойствами:

  • Правая (зависимая) часть каждой функциональной зависимости из
  • Левая часть (детерминант) каждой функциональной зависимости из
  • Ни одна функциональная зависимость из множества S не может быть

множества S содержит только один атрибут (т.е. является одноэлементным множеством).

множества S, в свою очередь, является неприводимой, т.е. ни один атрибут из детерминанта не может быть опущен без изменения замыкания S+ (без преобразования множества S в какое-то другое множество, не эквивалентное множеству S). В этом случае функциональная зависимость называется неприводимой слева.

удалена из множества s без изменения его замыкания S+ (т.е. без преобразования множества s в некоторое иное множество, не эквивалентное множеству S).

 

Основы моделей данных: элементы ER-модели; структурные ограничения ER-модели; реляционные модели

Рейтинг пользователей: / 1
ХудшийЛучший 

Процесс проектирования баз данных с использованием технологии сущность-связь (ER диаграммы) можно представить в виде:

Предметная область- ER проект – Реляционная система – Реляционная СУБД

Элементы ER модели –

a)         множество сущностей (Сущность – абстрактный объект определенного типа, например в бд кинофильм, актёр - сущность)

b)         атрибуты(Атрибут – свойство множества сущностей или связей. Атрибут сущности содержит значения, описывающие каждую сущность. Например у сущности человек атрибут - пол)

c)         множество связей (связь – осмысленная ассоциация между сущностями разных типов. Множество связей является набором ассоциаций между двумя(или более) множествами сущностей-участников. Например, сущность Владелец связана с сущностью Недвижимость с помощью связи - владеет)

Структурные ограничения

Связь один к одному

Если каждый экземпляр множества Е посредством связи R может быть соединен не более чем с одним экземпляром F, и каждый экземпляр множества F также может быть соединен не более чем с одним экземпляром E, то говорят что R – это связь один к одному, т.е. каждый экземпляр одного множества сущностей допускает соединение не более чем с одним экземпляром другого множества сущностей.

Связь один ко многим

Если каждый экземпляр множества Е посредством связи R может быть соединен более чем с одним экземпляром F, то говорят что R представляет связь один ко многим.

Связь многие ко многим

Если связь R в направлении от E к F относится к типу один ко многим и от F к E также относится к типу один ко многим, то имеет место связь типа многие ко многим.

Реляционные модели

Почти все современные системы основаны на реляционной (relational) модели управления базами данных. Название реляционная связано с тем, что каждая запись в такой базе данных содержит информацию, относящуюся только к одному конкретному объекту.

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

Модель, созданная на этапе инфологического моделирования, в наибольшей степени удовлетворяет принципам реляционности. Однако для приведения этой модели к реляционной необходимо выполнить процедуру, называемую нормализацией.

Теория нормализации оперирует с пятью нормальными формами. Эти формы предназначены для уменьшения избыточности информации, поэтому каждая последующая нормальная форма должна удовлетворять требованиям предыдущей и некоторым дополнительным условиям. При практическом проектировании баз данных четвертая и пятая формы, как правило, не используются. Мы ограничились рассмотрением первых четырех нормальных форм.

Введем понятия, необходимые для понимания процесса приведения модели к реляционной схеме.

Отношение - абстракция описываемого объекта как совокупность его свойств. Проводя инфологический этап проектирования, мы говорили об абстракции объектов и приписывали им некоторые свойства. Теперь же, проводя концептуальное проектирование, мы переходим к следующему уровню абстракции. На данном этапе объектов, как таковых, уже не существует. Мы оперируем совокупностью свойств, которые и определяют объект.

Экземпляр отношения - совокупность значений свойств конкретного объекта.

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

Простой атрибут - атрибут, значения которого неделимы.

Сложный атрибут - атрибут, значением которого является совокупность значений нескольких различных свойств объекта или несколько значений одного свойства.

Требования к реляционным моделям

Рациональные варианты концептуальной схемы базы данных должны удовлетворять третьей нормальной форме, а также следующим требованиям:

•          Выбранный перечень отношений должен быть минимален. Отношение используется, если только его необходимость обусловлена задачами.

•          Выбранный перечень атрибутов должен быть минимален. Атрибут включается в отношение только в том случае, если он будет использоваться.

•          Первичный ключ отношения должен быть минимальным. То есть невозможно исключить ни один атрибут из идентифицирующей совокупности атрибутов, не нарушив при этом однозначной идентификации.

•          При выполнении операций над данными не должно возникать трудностей.

Графическая интерпретация реляционной схемы

Концептуальная модель, реализованная в виде реляционной схемы, имеет свои правила графического представления:

•          Отношение представляется в виде полоски, содержащей имена всех атрибутов. Имя отношения пишется над ней.

•          Первичный ключ отношения должен быть выделен жирной рамкой.

•          Связи, определенные между отношениями, должны быть показаны линиями, проведенными между связующими атрибутами. Значения экземпляров связующих атрибутов должны совпадать.

 

Целостность реляционных данных

Во второй части реляционной модели данных определяются два ограничения, которые должны выполняться в любой реляционной базе данных. Это:

  • Целостность сущностей.
  • Целостность внешних ключей.

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

Целостность сущностей

Т.к. потенциальные ключи фактически служат идентификаторами объектов предметной области (т.е. предназначены для различения объектов), то значения этих идентификаторов не могут содержать неизвестные значения. Действительно, если бы идентификаторы могли содержать null-значения, то мы не могли бы дать ответ "да" или "нет" на вопрос, совпадают или нет два идентификатора.

Это определяет следующее правило целостности сущностей:

Правило целостности сущностей. Атрибуты, входящие в состав некоторого потенциального ключа не могут принимать null-значений.

Целостность внешних ключей

Т.к. внешние ключи фактически служат ссылками на кортежи в другом (или в том же самом) отношении, то эти ссылки не должны указывать на несуществующие объекты. Это определяет следующее правило целостности внешних ключей:

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

Замечания к правилам целостности сущностей и внешних ключей:

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

Действительно, в определении потенциального ключа требуется, чтобы потенциальный ключ обладал свойством уникальности. Это фактически означает, что мы должны уметь различать значения потенциальных ключей, т.е. при сравнении двух значений потенциального ключа мы всегда должны получать значения либо ИСТИНА, либо ЛОЖЬ. Но любое сравнение, в которое входит null-значение, принимает значение U - НЕИЗВЕСТНО, откуда следует, что атрибуты потенциального ключа не могут содержать null-значений.

Таким образом, с точки зрения реляционной теории, явная формулировка правил целостности является излишней - они автоматически вытекают из определений понятий ключа и внешнего ключа.

Тем не менее, явная формулировка правил целостности имеет определенный практический смысл. В большинстве серьезных СУБД за выполнением этих ограничений следит сама СУБД, если, конечно, пользователь явно объявил потенциальные и внешние ключи. Но, во-первых, для некоторых систем можно допустить, чтобы эти ограничения не выполнялись, а во-вторых, некоторые системы просто не поддерживают понятия целостности, например, некоторые "настольные" СУБД типа FoxPro 2.5. В этих случаях за целостностью данных должен следить сам пользователь, или программист, разрабатывающий приложение для пользователя.

Явная формулировка правил целостности помогает четко понять, какие опасности несет в себе пренебрежение этими правилами.

Операции, могущие нарушить ссылочную целостность

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

 
<< Первая < Предыдущая 1 2 3 4 5 6 Следующая > Последняя >>

Страница 1 из 6
Программируем на C#, интересные статьи, книги, музыка; Костя Карпов.