Нет!

52. Можно ли с использованием операций манипулирования данными изменить сразу несколько строк?

Да!

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

INSERT INTO имя_таблицы [(<список столбцов>) ] VALUES (<список значений>)

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

54. Как можно вводить неопределенные значения?

Null

55. Когда задание списка задание списка имен атрибутов операторе INSERT обязательно?

Когда не на всю строку

56. Как можно ввести много строк в одну таблицу?

UPDATE имя_таблицы

SET {имя_столбца = новое_значение [,...]}

[WHERE условие_отбора]

57. Сколько строк удалит оператор Delete from R1?

все

58. Можно ли одним оператором обновить сразу несколько строк?

да

59. Можно ли одним оператором обновить сразу несколько столбцов?

Ээ.. да?

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

Да, update name_table set pensioner=”da” where datarozd<1952 and sex = male pr datarozd<1957 and sex = female

Тема 5. Проектирование баз данных

61. Зачем нужен процесс проектирования базы данных?

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

• словесное описание информационных объектов предметной области;

• проектирование инфологической модели предметной области — частично формализованное описание объектов предметной области в терминах некоторой инфологической модели, например в терминах ER (Entity RelationShip)-модели;

• даталогическое или логическое проектирование БД, т. е. описание БД в терминах принятой даталогической модели данных;

• физическое проектирование БД, т. е. выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

62. Почему проект базы данных может быть плохим?

63. Что необходимо анализировать при построении базы данных?

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

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

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

64. Дайте определение понятию функциональная зависимость.

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

65. Может ли быть функциональная зависимость между двумя отношениями?

66. Может ли в одном отношении быть несколько функциональных зависимостей?

Функциональной зависимостью набора атрибутов В отношения R от набора атрибутов A того же отношения, обозначаемой как

R.A -> R.B или A -> B,

называется такое соотношение проекций R[A] и R[B], при котором в каждый момент времени любому элементу проекции R[A] соответствует только один элемент проекции R[B], входящий вместе с ним в какой либо кортеж отношения R. Функциональная зависимость R.A -> R.B называется полной, если набор атрибутов B функционально зависит от A и не зависит функционально от любого подмножества A, т. е. R.A -> R.B называется полной, если , что читается следующим образом: для любого A1, являющегося подмножеством А, R.B функционально не зависит от R.A1, в противном случае зависимость R.A -> R.B называется неполной.

Функциональная зависимость R.A -> R.B называется транзитивной, если существует набор атрибутов С такой, что

• С не является подмножеством А;

• С не включает в себя В, существует функциональная зависимость R.A -> R.C;

• не существует функциональной зависимости R.С -> R.А;

• существует функциональная зависимость R.С -> R.В.

67. Могут ли функциональные зависимости изменяться с течением времени?

68. Могут ли быть транзитивные функциональные зависимости в бинарных отношениях?

69. Чем отличается функциональная зависимость от многозначной?

70. Нормализация повышает скорость обработки информации?

Да

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

Корректной схемой БД называется схема БД, в которой отсутствуют нежелательные функциональные зависимости.

Процесс разработки корректной схемы реляционной БД называется логическим проектированием БД. 

Проектирование схемы БД может быть выполнено двумя путями:

71. Каковы недостатки избыточности в базах данных?

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

72. Какие типы связей между сущностями допустимы в ER-модели?

По типам взаимосвязей они делятся на обязательные и необязательные, а по мощности на связи типа «один к одному»(1:1), «один ко многим»(1:М) и «многие ко многим»(М:М).

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

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

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

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

Каждый атрибут сущности становится атрибутом соответствующего отношения. Переименование атрибутов должно происходить в соответствии с теми же правилами, что и переименование отношений. Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута (т. е. допустимость или недопустимость NULL значений для него).

Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL).

В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREIGN KEY).

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

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

Разрешение связей типа «многие ко многим»: введением специального дополнительного связующего отношения, которое связано с каждым исходным связью «один ко многим». Атрибутами этого отношения являются первичные ключи связываемых отношений.

76. Что такое суперсущность и как это понятие используется в моделировании БД?

77. Каков формат оператора описания таблицы? Каков порядок создания таблиц?

78. Какие ограничения на столбцы бывают и каков формат их описания?

79. Когда первичный ключ не может быть описан в рамках ограничения столбца?

80. Что такое ограничения типа UNIQUE и когда они используются, приведите примеры этих ограничений.

Процесс создания таблицы включает следующие действия:

• задать имя таблицы;

• задать перечень столбцов с указанием типов данных;

• для каждого столбца задать ограничения:

  • принадлежность к первичному ключу,

  • допустимость неопределенных значений,

  • наличие некоторых ограничений на значения столбца,

  • существование значений по умолчанию, т. е. тех, которые вводятся, если в операторе ввода отсутствует конкретное значение,

  • принадлежность к внешнему ключу.

• задать общие ограничения на таблицу.

Оператор создания таблицы:

CREATE TABLE <имя таблицы>

(<определение столбца1>[, <определение столбца2>, ...][, <ограничение на таблицу1>][,<ограничение на таблицу2>]...)

<определение столбца>::= <имя столбца> <тип данных>

[<ограничение на обязательность >,][<ограничение уникальности>,]

[<ограничение значения по умолчанию>,][<ограничение на значение>]

[, <ограничение по ссылкам>]

<тип данных>::= integer | smallint | char(n)| varchar(n)| datatime | ...

<ограничение на обязательность>::= NOT NULL | NULL

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

<ограничение значения по умолчанию>::=DEFAULT { const | function() }

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

<ограничение уникальности>::= UNIQUE | PRIMARY KEY

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

<ограничение на значение>::= CHECK (<условие проверки>)

В качестве условия проверки используется логическое выражение, которое принимает значение «истина» в случае ввода допустимого значения и «ложь» в противном случае.

<Ограничение по ссылкам>::= FOREIGN KEY <имя родительской таблицы> (<имя столбца в родительской таблице>)

Ограничение по ссылкам определяет моделирование связи между таблицами

Ограничения на таблицу задаются тогда, когда невозможно задать данное ограничение на уровне одного столбца. Например, если первичный ключ состоит из нескольких атрибутов, то невозможно определить это ограничение на уровне одного столбца. В этом случае данное ограничение задается после описания всех столбцов отдельным ограничением. Все ограничения на уровне таблицы могут иметь тип и специальное имя. Тип ограничений на уровне таблицы: PRIMARY KEY, FOREIGN KEY, CHECK,UNIQUE.

Синтаксис ограничения на уровне таблицы:

Constraint <имя ограничения> <тип ограничения> (выражение).

Например, если мы имеем ограничение типа первичный ключ, то это может быть представлено следующим образом:

Constraint PK_EX PRIMARY KEY (ISBN,INV_NUM) — это означает, что у нас составной первичный ключ, который имеет 2 атрибута с именами ISBN и INV_NUM.

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

82. Каков формат оператора модификации таблицы?

83. Каков формат оператора удаления таблицы? Каков порядок удаления таблиц?

Drop table <name_table>

Тема 6. Многопользовательский режим работы с БД. Модели «клиент-сервер» в системах баз данных. Архитектура серверов баз данных

84. Может ли быть реализована модель «клиент-сервер» на одном компьютере? Приведите примеры.

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

85. Где находится СУБД в модели «файл-сервер»?

Процессор управления данными (Database Manager System Processing) — это собственно СУБД, которая обеспечивает хранение и управление базами данных. В идеале функции СУБД должны быть скрыты от бизнес-логики приложения, однако для рассмотрения архитектуры приложения нам надо их выделить в отдельную часть приложения.