Шпаргалка по "Информатике"

лишь допустимые значения.

3. Ссылочная   целостность   -  набор   правил,   обеспечивающих

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

4. Пользовательские правила целостности - это любые правила

целостности, не относящиеся к первым трем категориям. Из этих четырех правил наиболее важными  являются 1 и 3. эти требования должны поддерживаться любой СУБД. Ограничение целостности. Пусть имеется система, в которой хранятся данные с подразделениях и работающих в них сотрудниках. Списоь подразделений хранится в таблице DEPART, где Deptld -идентификатор подразделения, Dept_Name - наименование подразделения, Dept_Kol - количество сотрудников в подразделении. Список сотрудников хранится в таблице PERSON где Persld - идентификатор сотрудника, PersName - имя сотрудника, Deptld - идентификатор подразделения, в котором работает сотрудник: Ограничение целостности этой базы данных состоит в том, что поле DeptKol не может заполняться произвольными значениями - это поле должно содержать количество сотрудников, реально числящихся в подразделении. С учетом этого ограничения можно заключить, что вставка нового сотрудника в таблицу не может быть выполнена одной операцией. При вставке нового сотрудника необходимо одновременно увеличить значение поля DeptKol: Шаг 1. Вставить сотрудника в таблицу PERSON: INSERT INTO PERSON (6, Муфтахов, 1) Шаг 2. Увеличить значение поля Dept_Kol: UPDATE DEPART SET Dept=Dept+l WHERE Dept_Id=l Если после выполнения первой операции и довыполнения второй произойдет сбой системы, то реально будет выполнена только первая операция и база данных остается в нецелостном состоянии. Потенциальные ключи

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

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

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

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

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

42. Команды, используемые  для создания файлов БД программными средствами.

СОЗДАНИЕ  ФАЙЛА ТАБЛИЦЫ ДАННЫХ и ОКНО РЕДАКТИРОВАНИЯ ДАННЫХ VF 5/0

Создание файла  таблицы данных включает два этапа: создание структуры файла и заполнение файла данными.СОЗДАНИЕ СТРУКТУРЫ ФАЙЛА рассмотрим на конкретном примере: Структура таблицы типа (*.DBF) создается командой: СRЕАТЕ<имя, можно без расширения>(перед именем указывается путь, если его не указать, то файл запишется в каталог VF по умолчанию) По умолчанию Visual FoxPro присваивает "родовое" расширение (.dbf), принятое для всех таблиц данных, отвечающих стандарту dBASE (соблюдаются большинством СУБД). На экране появится диалоговое окно создания/корректировки таблиц баз данных, а именно для каждого вводимого поля:

Имя

Name

Туре

Длина

Точность (число дробных позиций) для числов

Index

Индекс поля по возрастанию/по убыванию

Null

Пустое значение поля таблицы данных

Окно Table Designer имеет три вкладки: Fields, Indexes, Table.

Вкладка   Table   содержит   сведения   о   количестве   записей

(Records)   таблицы,      количестве   полей   (Fields)   их   длине

(Length) в байтах (1 байт отводится под запоминание имени

таблицы),   а также полный путь к данному  файлу данных и

т.д.

Вкладка   Indexes      позволяет   создавать   теги   структурного

составного  индекса.

Простой   способ   создания   таблицы   через   системное   меню

File/New. В диалоговом окне New (создание новых файлов баз

данных, запросов, таблиц и т.д.) выбирается опция Table, после

кнопка New File,  и   VF предлагает сохранить  таблицу  под

определенным   именем   на   диске.   Если   выбрать      кнопку

Wizards, то произойдет вызов мастера (Wizards) - это означает,

что Ваша работа будет протекать в режиме "вопрос- ответ".

Порядок расположения полей    может быть изменен. Можно

удалять   имеющиеся   и  дополнять   новые  поля  (<Insert>   и

<Delete>).

Для изменения структуры таблицы используется команда:

MODIFY STRUCTURE В диалоговом окне Table Designer в режиме модификации Вы можно удалять, переименовывать, дополнять поля таблицы данных, а также менять их параметры. Изменяемый файл должен быть предварительно открыт (при изменении таблицы старые структуры сохраняются на диске с расширением ВАК для файлов DBF и ТВК - для FPT файлов (хранящих Memo-поля).

На  экран можно вывести/убрать статусную  строку с помощью команды

SET STATUS ON/OFF Она содержит следующую информацию:  имя выполняемой программы, текущий диск, имя открытой таблицы или БД и т.д., номер текущей записи, общее число записей в таблице, признак  пометки  текущей  записи  к удалению  (слово Del), положение клавиш NumLock и CapsLock (Num и Caps). Переименование таблицы данных производится с помощью команды RENAME <старое_имя_файла с расширением> ТО <новое_имя_файла с расширением> Данная команда переименовывает файл любого типа. 

25.Методология  проектирования БД. Известные подходы  к проектированию БД.

Проектирование БД

Методология поэтапного проектирования БД может  быть

определена  как построение структуры БД на основе

информационных  и процедурных требований пользователей.

В настоящее  время существуют следующие этапы  построения БД:

1. Этап- Анализ требований.
2. Этап- Концептуальное (логическое) проектирование.
3. Этап- Проектирование реализации.
4. Этап- Физическое проектирование.
5. Этап- Машинное проектирование.

Каждый этап проектирования характеризуется набором  методов проектирования и критериями оценки альтернативных вариантов. Выбор критериев оценки альтернативных вариантов является слабым звеном в проектировании БД. Это обусловлено следующими факторами:

1. Многовариантность решения задачи проектирования.
2. Сложность оценки альтернативных вариантов. Большинство из критериев не имеет количественной оценки, их важность изменяется во времени, время действия различных критериев не одинакова.

В качестве критериев  оценки эффективности проектирования БД используются следующие:

1. Количественная - время отклика на запрос, размеры и стоимость памяти, время и стоимость разработки, стоимость обновления и некоторые другие.
2. Качественные - гибкость, адаптивность, программная и информационная совместимость с другими системами. Возможность изменения структуры БД, удобство пользовательского интерфейса и т.д.

28.Проектирование БД. Этап «Allium требований». Анализ требований

На этом этапе  устанавливаются цели заказчика, на основе которых выделяются

требования  к БД. Определяются потенциальные  пользователи системы и,

соответственно, требования пользователей к БД. Установленные требования

документируются в форме доступной конечному  пользователю,

проектировщику  и разработчику БД.

Разрабатываются и утверждаются техническое задание  на разработку БД.

Данный этап является наиболее трудоемким во времени и наименее

формализованное из всех этапов проектирования.

Основной задачей является сбор требований, предъявляемый к  содержанию и

процессам обработки  данных всеми пользователями БД.

Путем опроса персонала выявляются и разделяются  информационные потоки и

операции над ними. Составляется информационная модель предметной области.

На этом этапе  же формируется ограничения по безопасности, надежности и др.

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

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

проектирования.

Здесь принято разделять  информацию на две категории:

а) ISP- информация. Она определяет структурное представление о 
предметной области, и описывает концептуальные объекты и связи, 
исследуемые в предметной области. Данный тип информации не связан с 
конкретными приложениями и способами обработки данных.

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

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

Анализ процедурных  требований необходимо проводить после  идентификации элементов данных и составления словаря данных на основании сформулированных информационных требований. Характеристики задачи:

1. Задача - это уникальная единица деятельности, состоящая из набора последовательно выполняемых шагов.
2. Все шаги одной из задач направлены на достижение одной цели.
3. На каждом шаге задачи используют один и тот же набор данных.
4. Выявление связей между задачами и данными имеет важное значение для следующих этапов.

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

присваивается значение, определяется частота выполнения задач, при

необходимости задачи классифицируются на производственные и

управленческие.

Процедурные требования разделяются на три группы:

1. Тривиальные операции- просмотр, изменение, удаление, добавление.
2. Не тривиальные операции - поиск, упорядочивание данных, а также, способы обработки данных, взятых из предметной области.
3. Отчеты - включают в себя не тривиальные операции, необходимые для формирования отчетов и выходных форм.

Этап "Анализ требований " целесообразно разбить на три  части:

1. Анализ требований и информационных потребностей.
2. Выявление информационных объектов и связей между ними.
3. Формирование допущений и ограничений.

сводится  к полной функциональной зависимости  от возможного

 

19. Понятие  целостности и непротиворечивости  БД Ограничения целостности. Понятие  потенциального альтернативного  ключей.  Первичные  и  внешние     ключи

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

1. Целостная   сущность.   Любой   кортеж   любого   отношения

должен быть отличен  от любого другого кортежа этого  отношения (каждое отношение должно иметь первичный ключ).

2. Целостность доменов.     Каждый атрибут должен  понимать

лишь допустимые значения.

3. Ссылочная  целостность  -  набор правил,  обеспечивающих

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

4. Пользовательские правила целостности - это любые правила

целостности, не относящиеся к первым трем категориям. Из этих четырех правил наиболее важными являются 1 и 3. эти требования должны поддерживаться любой СУБД. Ограничение целостности. Пусть имеется система, в которой хранятся данные с подразделениях и работающих в них сотрудниках. Список подразделений хранится в таблице DEPART, где Deptld • идентификатор подразделения, DeptName - наименование подразделения, DeptKol - количество сотрудников в подразделении. Список сотрудников хранится в таблице PERSON где Persld - идентификатор сотрудника, PersName - имя сотрудника, Deptld - идентификатор подразделения, в котором работает сотрудник: Ограничение целостности этой базы данных состоит в том, что поле DeptKol не может заполняться произвольными значениями - это поле должно содержать количество сотрудников, реально числящихся в подразделении. С учетом этого ограничения можно заключить, что вставка нового сотрудника в таблицу не может быть выполнена одной операцией. При вставке нового сотрудника необходимо одновременно увеличить значение поля DeptKol: Шаг 1. Вставить сотрудника в таблицу PERSON: INSERT INTO PERSON (6, Муфтахов, 1) Шаг 2. Увеличить значение поля DeptKol: UPDATE DEPART SET Dept=Dept+l WHERE Dept_Id=l Если после выполнения первой операции и довыполнения второй произойдет сбой системы, то реально будет выполнена только первая операция и база данных остается в нецелостном состоянии. Потенциальные ключи