Тема: Как изменить владельца базы данных sql ?
Как изменить владельца базы данных sql ?
- Просмотр профиля
- Сообщения форума
ISPmanager 5 хранит информацию обо всех сущностях в базе данных sqlite3 — ispmgr.db
Соответственно сменить владельца можно через базу.
- Просмотр профиля
- Сообщения форума
Сообщение от Fly
ISPmanager 5 хранит информацию обо всех сущностях в базе данных sqlite3 — ispmgr.db
Соответственно сменить владельца можно через базу.
- Просмотр профиля
- Сообщения форума
- Просмотр профиля
- Сообщения форума
- Просмотр профиля
- Сообщения форума
- Просмотр профиля
- Сообщения форума
Сообщение от Dasha
1. Не понимаю, почему убрали такую возможность. Я 5 дней не могу тупо сменить владельца базы.
2. Объясните русским языком, пошагово, для отсталого — как сменить владельца.
Это начинает становится каким-то сложным экзаменом.
Open Library — открытая библиотека учебной информации
Открытая библиотека для школьников и студентов. Лекции, конспекты и учебные материалы по всем научным направлениям.
Категории
Менеджмент Создание и управление базой данных MS SQL Server
Реализация баз данных и таблиц MS SQL Server
Нормализация схем отношений между таблицами и данными
Как же осуществляется нормализация схем отношений между данными и таблицами?
Язык нормальных форм констатирует наличие или отсутствие определенных функциональных зависимостей (ФЗ) в таблицах реляционной базы данных и указывает на уровень избыточности и надежности данных в нормализованных отношениях. Методы нормализации основываются на применении понятия ФЗ и способов манипулирования ими. При выполнении реляционных операций над таблицами в базе данных каждый тип ФЗ может порождать определенный тип аномалий, который будет нарушать целостность данных в базе данных. Нормальная форма (НФ) представляет собой ограничение на схему базы данных, вводимое с целью устранения определенных нежелательных свойств при выполнении реляционных операций.
Различают несколько типов нормальных форм. Каждая из них ограничивает присутствие определенного класса ФЗ в таблице и устраняет присущие этому классу ФЗ аномалии в выполнении реляционных операций.
На практике при работе с базами данных, которые проектировали не профессиональные разработчики, а обычные пользователи, иногда можно столкнуться с таблицами вида:
| Наименование | Город | Адрес | Эл.почта | www | Вид. | Конт.информация |
| Хлебозавод N1 | Санкт-Петербург | Невский пр., д.100 | info@hleb1.ru | www.hleb1.ru | Поставщик | Паутин, зам.директора, т.010 |
| Хлебозавод N1 | Санкт-Петербург | Невский пр., д.100 | info@hleb1.ru | www.hleb1.ru | Поставщик | Мюдведов, нач.отдела сбыта͵ т.110 |
| ООО «Хлебушко» | Оренбург | Ул.Пушкина, 7 | hleb@hmail.ru | Клиент | Сидоров, директор, т.00900 | |
| ПБОЮЛ «Омега» | Красноярск | Ул.Стальная, 45 | omega@mmaaiill.ru | Клиент | Иванов, директор, т.901091 |
Конечно же, такая структура является неоптимальной по многим причинам:
1) данные в таблице являются избыточными. К примеру, адрес одной и той же фирмы повторяется несколько раз. В случае если таблица будет большой, то из-за избыточных данных нам потребуется много места на хранение, а производительность работы с таблицей упадет;
2) очень легко ошибиться, указав разный адрес (или адрес по-разному для одной и той же фирмы);
3) при изменении, к примеру, адреса для фирмы нам потребуется данный адрес поменять во всех записях для данной фирмы.
Вместе с тем, проблема с нашей таблицей состоит по сути в том, что разнородные данные в столбце «конт.информация» слиты в единое целое. Один из принципов работы с базами данных состоит по сути в том, что обычно очень просто свести в результате запроса вместе данные из разных столбцов, и очень сложно – произвести дальнейшую детализацию, то есть выделить, к примеру, из последнего столбца телефон.
Прежде чем говорить о том, как именно решать рассмотренные проблемы, то есть нормализовать данные, крайне важно рассказать о нескольких принципах, которые лежат в основе нормализации.
Первый принцип – декомпозиция без потерь. Это значит, что после разбиения ненормализованной таблицы на несколько более мелких ее можно при желании объединить обратно без потери данных. Такое объединение обычно производится, конечно, не на уровне самой базы данных, а на уровне запросов.
Второй принцип – каждая запись сказать должна быть уникальна, то есть у нас должна быть возможность как-то отличать одну запись от другой. То есть каждая запись должна содержать в себе метку, которая уникально отличает ее от остальных записей. Такая метка принято называть ключом. Можно дать и более формальное определение ключа: ключ — ϶ᴛᴏ набор столбцов таблицы, значения которых уникально определяют строку.
Как выяснить, что в нашей таблице может быть ключом? Казалось бы, ответ прост – достаточно просто выполнить запрос к таблице и посмотреть, значения каких столбцов (или наборов столбцов) являются уникальными. При этом на практике все намного сложнее за счет того, что набор записей в таблице постоянно изменяется, и в нем могут появиться нарушающие значения.
К примеру, мы занимаемся автоматизацией работы очень маленькой фирмы, в которой всего три сотрудника – Иванов, Петров и Сидоров. Можно сделать ключом просто фамилию, но в этой ситуации мы столкнемся с проблемами, если фирма расширится и на работу придет однофамилец имеющегося сотрудника. Расширение ключа на еще два столбца – с именами и отчествами – также решение проблемы не является по причине того, что в итоге вполне может появиться полный тезка и однофамилец. Вместе с тем, если, к примеру, сотрудница сменит фамилию, то опять-таки могут возникнуть проблемы – она будет выглядеть для базы данных как новый сотрудник.
Пять нормальных форм
Таблица находится в первой нормальной форме (1НФ), если все атрибуты таблица являются простыми (требование атомарности атрибутов в реляционной модели), ᴛ.ᴇ. не имеют компонентов. Иными словами, атрибут (точнее, как мы покажем дальше, его домен) должен состоять из неделимых значений и не может включать в себя множество значений из более элементарных доменов. Так, к примеру, дата не может считаться простым атрибутом. В большинстве случаев выполнить это требование достаточно просто. Каждый простой атрибут должен иметь свою колонку в таблице. При этом это часто приводит к дублированию данных в таблице.
Типичным примером неатомарности атрибута являются так называемые повторяющиеся группы, представляющие массив значений атрибута.
На следующем рисунке представлено ненормализованная таблица SHIPMENT (ОТГРУЗКА). Она содержит повторяющиеся группы, представляющие массив значений, 1st Consignments, 2st Consignments, 3st Consignments (три партии грузов).
Атрибуты, характеризующие партию грузов (показаны на следующем рисунке), – Consignee (грузополучатель), Insured Value (застрахованная стоимость) и Declared Value (объявленная стоимость), — повторяются для каждой такой партии. Отметим, что для такой таблицы следует ввести бизнес-правило, требующее, чтобы груз состоял не более чем из трех партий, поскольку четвертую партию вставить в этой таблице некуда.
Использование таблицы, представленной не в 1НФ, может породить в нашем случае следующие проблемы:
· если груз аннулируется и строка, связанная с грузом, удаляется из таблицы, то вместе с ней удаляются все сведения о партиях груза на борту судна;
· если на склад прибывает новая партия груза, и она еще не включена в состав груза, подлежащего отправке, то сведения о партии заносить некуда;
· крайне важно вводить ограничение: в грузе не может быть более трех партий.
Приведение таблицы SHIPMENT к 1НФ заключается в изъятии данных о партиях груза из таблицы SHIPMENT и создании для них связанной подчиненной таблицы CONSIGNMENT (ПАРТИЯ_ГРУЗА). Результат приведения таблицы SHIPMENT к 1НФ представлен на предыдущем рисунке. Для такого представления сущности SHIPMENT не требуется вводить ограничительное бизнес-правило.
Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, процедура приведения таблицы к 1НФ состоит в вынесении неатомарных атрибутов в отдельную подчиненную таблицу.
Будем считать атрибут таблицы ключевым, если он является элементом какого-либо ключа таблицы. В противном случае атрибут будет считаться неключевым атрибутом. Так в таблице (Город, Адрес, Почтовый_индекс) все атрибуты являются ключевыми, поскольку при заданных ФЗ «город, адрес -> почтовый_индекс» и «почтовый_индекс -> город» ключами являются пары (город, адрес) и (адрес, почтовый_индекс).
Таблицв находится во второй нормальной форме (2НФ), если оно находится в 1НФ, и все неключевые атрибуты функционально полно зависят от составного ключа таблицы. Иными словами, 2НФ требует, чтобы таблица не содержала частичных ФЗ.
Вновь обратимся к рассмотрению таблицы SHIPMENT, представленного на предыдущем рисунке. Она содержит частичную ФЗ: неключевой атрибут Ship Capacity (грузоподъемность корабля) не зависит от ключевого атрибута Departure Date (даты убытия), а зависит от ключевого атрибута Ship Registration Number (регистрационный номер корабля).
Использование таблицы, представленной не во 2НФ, может породить следующие проблемы:
· невозможно занести в базу данных название и грузоподъемность корабля, который не доставил еще ни одного груза, — можно только ввести для него фиктивный груз;
· если удалить кортеж из Shipment после отправки груза, то потеряются все данные о кораблях, для которых в настоящее время нет груза;
· невозможно отразить факт переоборудования корабля и получения им новой грузоподъемности; если переписать все предыдущие кортежи об этом корабле, то получится, что он в прошлом плавал недогруженным или перегруженным.
Приведение таблицы SHIPMENT ко 2НФ заключается в изъятии атрибутов частичной ФЗ из нее и создании связанной подчиненной таблицы SHIP. Результат приведения SHIPMENT ко 2НФ представлен на следующем рисунке.
Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, процедура приведения таблицы ко 2НФ состоит в выполнении двух проекций: проекции без атрибутов частичной ФЗ и проекции на часть составного ключа и те атрибуты, которые от него зависят.
Таблицы находится в третьей нормальной форме (3НФ), если она находится во 2НФ, и все неключевые атрибуты зависят только от первичного ключа. Иными словами, 3НФ требует, чтобы таблица не содержала транзитивных ФЗ неключевых атрибутов от ключа.
Формально это требование можно сформулировать следующим образом: схема таблицы R находится в 3НФ, если не существует ключа Х для R, множества атрибутов и неключевого атрибута А из R, не принадлежащего Х или Y, таких, что: 1) имеет место в R, 2) имеет место в R, но 3) не имеет места в R.
ФЗ представляют не только ограничения целостности, налагаемые на таблицы, но и связи между атрибутами, если они (связи) сохраняются в базе данных. В случае если таблица содержит частичную зависимость — ключ и , то в каждом кортеже, используемом для хранения связи значений Х со значениями какого-либо другого атрибута͵ кроме А и Х, должна появиться связь между Y и A. Так, к примеру, адрес поставщика дублируется для каждого поставляемого товара в таблице ПОСТАВКИ. Использование 3НФ исключает возможность возникновения такой ситуации (см. условие 3 в формальном определении 3НФ).
Наличие транзитивной зависимости не позволяет связать значения Y и Х, если не существует значения А, связанного со значением Y. Это затрудняет вставку и обновление данных, которые крайне важно выполнить сразу для пары связей, а в случае удаления данных приводит к потере связи.
Вновь обратимся к рассмотрению таблицы SHIPMENT, представленной на предыдущем рисунке. Оно содержит транзитивную ФЗ: атрибут Customs Declaration (таможенная декларация) является по своей сути свойством атрибутов Origin (пункт отправления) и Destination (пункт назначения). Результат приведения SHIPMENT к 3НФ представлен на следующем рисунке.
Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, процедура приведения таблицы к 3НФ состоит в выполнении двух проекций: проекции по правой части транзитивной ФЗ и проекции по левой части транзитивной ФЗ.
3НФ упрощает решение проблем контроля избыточности данных, интерпретации пустых значений, контроля за операциями модификации данных, только если в таблицах отсутствуют какие-либо другие ФЗ, в частности обратные ФЗ неключевого атрибута на один из атрибутов составного первичного ключа или многозначные ФЗ. В противном случае вышеперечисленные проблемы остаются неразрешенными. Для устранения таких проблем, связанных с существованием обратных ФЗ неключевых атрибутов на часть составного ключа, была предложена усиленная 3НФ или НФ Бойса-Кодда.
Таблица находится в нормальной форме Бойса-Кодда (НФБК), если она находится в 3НФ, и в ней отсутствуют зависимости ключевых атрибутов от неключевых атрибутов. Иными словами, НФБК допускает наличие только таких нетривиальных ФЗ, в которых ключ определяет один или более других атрибутов: , где включает некоторый ключ.
Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, схема таблицы в НФБК обладает теми же достоинствами, что и схема в 3НФ, но устраняет некоторые дополнительные аномалии, не устраняемые 3НФ. К примеру, в таблицах (Город, Адрес, Почтовый_индекс), находящихся в 3НФ, невозможно записать кортеж для города с известным почтовым индексом, если не известен адрес с этим почтовым индексом. Данная таблица не находится в НФБК, так как имеет место ФЗ Почтовый_индекс Город, а атрибут Почтовый_индекс не является ключом этой таблицы.
В отличие от 3НФ, исходные таблицы не всегда бывают приведены в НФБК.
Предположим, что экипаж судна разделен на команды, каждая из которых отвечает за разные виды работ. Члены экипажа могут входить в разные команды, но в каждую команду входит только один руководитель. Команда может иметь несколько руководителей. Каждый член экипажа может руководить только одной командой. Это задается следующей таблицей:
| Таблица КОМАНДА | ||
| Член экипажа | команда | Руководитель |
| Иванов | Наблюдение | Прохоров |
| Иванов | Питание | Макаров |
| Петров | Наблюдение | Леонтьев |
| Модин | Наблюдение | Прохоров |
| Васин | Питание | Лазарев |
| Фролов | Обслуживание | Сидоров |
| Ивлев | Обслуживание | Сидоров |
Таблица находится в 3НФ, однако содержит аномалию удаления. В случае если Петрова удалить из команды наблюдения, то будет потеряна информация о том, что Леонтьев является руководителем команды наблюдения, и при назначении нового члена экипажа в команду наблюдения не будет известно, что у нее есть еще один руководитель, кроме Прохорова.
Заметим, что в предыдущих случаях разбиение происходило без создания избыточности данных из-за обратной зависимости атрибута на часть ключа. Приведение таблиц к НФБК заключается в создании дополнительной таблицы, содержащего сведения о руководителях команд (следующая таблица).
| Таблица РУКОВОДИТЕЛЬ_КОМАНДЫ | |
| Команда | Руководитель |
| Наблюдение | Прохоров |
| Питание | Макаров |
| Наблюдение | Леонтьев |
| Питание | Лазарев |
| Обслуживание | Сидоров |
Результат приведения таблицы КОМАНДА к НФБК представлен на следующем рисунке.
Таблица находится в четвертой нормальной форме (4НФ), если она находится в 3НФ или НФБК и все независимые многозначные ФЗ разнесены в отдельные таблицы с одним и тем же ключом. Иными словами, 4НФ применяется при наличии в таблицах более чем одной многозначной ФЗ и требует, чтобы они не содержали независимых многозначных ФЗ.
Рассмотрим таблицу, содержащую сведения о кораблях (Ship), совершаемых ими рейсах (Voyage) и капитанах (Captain). Это представлено в таблице ниже и на следующем рисунке.
| Таблица КАПИТАН_КОРАБЛЬ_РЕЙС | ||
| Акбар | Иванов | Красноярск – Дудинка |
| Акбар | Петров | Красноярск — Дудинка |
| Акбар | Ивлев | Красноярск — Дудинка |
| Акбар | Прохоров | Красноярск — Дудинка |
| Акбар | Лазарев | Дудинка — Мурманск |
| Акбар | Прохоров | Дудинка — Лондон |
| Жучка | Петров | Дудинка — Марсель |
| Жучка | Фролов | Дудинка – Стокгольм |
| Жучка | Ивлев | Дудинка – Стокгольм |
Таблица находится в НФБК и содержит только многозначные ФЗ. При этом имеет место аномалия удаления: если капитан Петров уйдет в отставку, и все кортежи о нем будут удалены, то будут потеряны сведения о том, что корабль «Жучка» совершает рейсы Дудинка — Марсель. В случае если добавить новый рейс, то, возможно, придется ввести несколько кортежей в наши таблицы.
Приведение таблиц к 4НФ заключается в выделении для каждой многозначной ФЗ своей таблице, как показано на следующем рисунке.
Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, процедура приведения таблиц к 4НФ сводится к выполнению нескольких проекций, в данном случае двух проекций.
Как можно заметить, нормализация выполнялась путем разложения (декомпозиции) схем таблиц. Очевидно, что при таком подходе должен соблюдаться принцип обратимости: соединение проекций должно приводить к исходным таблицам. Это предполагает отсутствие потери кортежей; появление ранее не существовавших кортежей; сохранение ФЗ (семантика взаимосвязей между данными не должна нарушаться).
На самом же деле декомпозиция схем не всегда гарантирует обратимость. Это обстоятельство связано с существованием класса ФЗ по соединению. В случае если таблица удовлетворяет ФЗ по соединению, то оно может быть восстановлено по своим проекциям. Таблицы, содержащие более трех МФЗ, требуют особого внимания при построении логической модели реляционной базы данных. Также 4НФ не устраняет избыточность данных полностью, в связи с этим требуется дальнейшая декомпозиция схем.
Таблица находится в пятой нормальной форме (5НФ), если оно находится в 4НФ и удовлетворяет зависимости по соединению относительно своих проекций. 5НФ называют также нормальной формой с проецированием соединений. Она используется для разрешения трех и более таблиц, которые связаны более чем тремя ФЗ по типу «многие-ко-многим».
Рассмотрим таблицы с несколькими многозначными зависимостями, представленные на следующем рисунке.
Рассмотрим сначала ее как три изолированных таблицы со степенью связи «многие-ко-многим»:
Каждый автомобиль имеет определенный цвет и модель. Некоторые цвета характерны только для определенных моделей. Такие таблицы разрешаются введением связывающих таблиц, в данном случае таких таблиц три:
Предположим, что клиент желает приобрести автомобиль синего цвета модели С, при этом марка автомобиля роли не играет. Запрос к базе данных на поиск такого автомобиля будет содержать два соединения между тремя таблицами Car, Car Color и Car Model по атрибуту наименование машины и два предиката: цвет = синий и модель = С.
Результат выполнения запроса будет удивителен: есть и Волга, и Жигули. При этом из таблицы Model Color видно, что автомобиля синего цвета модели С не существует. Появляется несуществующий кортеж. Такое явление представляет собой аномалию проецирования соединений и пример нарушения 5НФ.
Приведение таблиц к 5НФ заключается во введении еще одной таблицы, связывающей три исходных, как показано на следующем рисунке.
Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, процедура приведения таблицы, содержащей многозначные ФЗ, к 5НФ состоит в построении связывающей таблицы, позволяющей исключить появление в соединениях ложных кортежей.
Следовательно, каждая нормальная форма ограничивает определенный тип ФЗ и устраняет аномалии обработки данных. Нормальные формы характеризуются следующими свойствами:
· 1НФ – все атрибуты простые;
· 2НФ – таблица находится в 1НФ и не содержит частичных ФЗ;
· 3НФ – таблица находится во 2НФ и не содержит транзитивных ФЗ от ключа;
· НФБК – таблица находится в 3НФ и не содержит ФЗ ключей от неключевых атрибутов;
· 4НФ, применяется при наличии более чем одной многозначной ФЗ. Таблица находится в НФБК или 3НФ и не содержит независимых многозначных ФЗ;
· 5НФ – таблица находится в 4НФ и не содержит ФЗ по соединению.
Создание базы данных SQL Server
Первым этапом реализации физической базы данных является создание объекта «база данных». Создают данный объект и определяют его характеристики на основе информации, полученной при определении требований к системе и деталей, определенных при проектировании базы данных. Характеристики объекта «база данных» можно изменить и после его создания.
Во время создания базы данных крайне важно определить ее имя, размер, а также файлы и группы файлов, в которых она будет храниться. Прежде чем создавать базу данных, следует усвоить несколько правил:
• право на создание базы данных по умолчанию принадлежит членам стандартных ролей на сервере sysadmin и dbcreator. однако это право может быть предоставлено и другим пользователям;
• пользователь, создавший базу данных, становится ее владельцем;
• на сервере может быть создано до 32 767 баз данных;
• имя базы данных должно соответствовать правилам, определенным для идентификаторов.
Для хранения базы данных используются три типа файлов: основные, в которых находится информация для запуска; дополнительные, в которых хранятся все данные, не поместившиеся в основном файле; файлы журнала транзакций, содержащие данные журнала, необходимые для восстановления базы данных. Любая база данных состоит по крайней мере из двух файлов: основного и файла журнала транзакций.
Во время создания базы данных составляющие ее файлы заполняются нулевыми значениями, чтобы уничтожить все данные, которые могли остаться на диске после удаленных ранее файлов. Хотя из-за этого файлы создаются дольше, во время обычной работы базы данных ОС освобождается от заполнения файлов нулевыми значениями при первой записи в них. Эта функция повышает производительность каждодневных операций.
При создании базы данных следует задать ее максимальный размер. Это позволяет предотвратить рост файла при добавлении данных вплоть до исчерпания свободного места на диске.
SQL Server создает новую базу данных в два этапа:
1. используя копию базы Model, SQL Server инициализирует новую базу данных и ее метаданные;
2. после этого SQL Server заполняет оставшуюся часть базы данных (кроме страниц с внутренними данными, отражающими использование дискового пространства, занятого базой данных) пустыми страницами.
Любые пользовательские объекты из базы Model копируются во все новые базы данных. К базе данных Model можно добавлять любые объекты: таблицы, представления, хранимые процедуры, типы данных и т. д., которые следует включить в новые базы данных. Каждая новая база данных наследует все настроечные параметры базы Model.
Компоненты базы данных SQL Server
База данных SQL Server состоит из набора таблиц с данными и других объектов; представлений, индексов, хранимых процедур и триггеров, обеспечивающих обработку данных. В базах данных обычно хранится информация, связанная с некоторым субъектом или процессом, к примеру сведения о покупателях, используемые розничными торговцами, или данные производителя о продажах товаре.
Методы создания баз данных SQL Server
SQL Server предоставляет несколько методов для создания базы данных, в том числе оператор Trarsact-SQL CREATE DATABASE и мастер Create Database, который можно вызвать в SQL Server Management Studio.
Средств оператора CREATE DATABASE обычно достаточно, чтобы создать базу данных со всеми ее файлами. Оператор CREATE DATABASE позволяет задать несколько параметров, определяющих характеристики базы данных, к примеру максимальный размер или инкремент роста файла. При исполнении простого оператора CREATE DATABASE <имя_БД> без параметров создается база данных того же размера, что и Model. Подробное описание параметров оператора CREATE DATABASE можно найти в справочнике по языку Transact-SQL в SQL Server Books Online.
Оператор CREATE DATABASE можно исполнить в SQL Query Analyzer. Следующая программа-пример создает базу данных под названием Products и задает для нее один основной файл. Также автоматически создается файл журнала транзакций размером 1 Мб. Поскольку в параметре SIZE для основного файла не заданы ни мегабайты, ни килобайты, размер основного файла измеряется в мегабайтах. Поскольку не заданы параметры файла журнала транзакций, в том числе параметр MAXSIZE, данный файл может увеличиваться, пока не заполнит все место на диске.
CREATE DATABASE Products
Аналогичного результата можно достичь с использованием «мастера» CreateDatabase в составе SQL Server Management Studio или консоли выполнения запросов sqlcmd.exe из состава инструментария, поставляемого с SQL Server.
Управление базой данных SQL Server
С новой базой данных SQL Server можно выполнять различные действия: просматривать сведения о ней, модифицировать ее характеристики или удалить ее.
В случае если крайне важно устранить неполадки и принять решения о внесении изменений в базу данных, то стоит просмотреть определение базы данных и параметры ее конфигурации.
SQL Server предоставляет несколько методов просмотра сведений о базе данных: системную хранимую процедуру sp_helpdb, оператор DATABASEPROPERTYEX и SQL Server Management Studio.
Системная хранимая процедура sp_helpdb выдает информацию обо всех базах данных или только о заданной. Оператор DATABASEPROPERTYEX возвращает текущее значение настроечного параметра или свойства только для заданной базы данных. За один раз данный оператор возвращает значение лишь одного свойства. Для просмотра настроечных параметров базы данных можно также использовать SQL Server Management Studio. Для этого в консоли достаточно открыть диалоговое окно Properties для нужной базы данных. В диалоговом окне Properties имеется несколько вкладок со сведениями о конфигурации базы данных. Использование данных консоли, процедуры и оператора очевидны и примеры их работы мы по понятным причинам приводить не будем.
Разрешается модифицировать исходное определение базы данных после ее создания. При этом иногда перед внесением изменений требуется вывести базу данных из обычного режима работы. В следующей таблице перечислены типы изменений свойств базы данных с указанием способа их внесения. Подробно решение каждой из задач описано в SQL Server Books Online.
| Тип изменения | Методы внесения изменения |
| Увеличение размера базы данных | Оператор ALTER DATABASE, свойства базы данных в SQL Server Management Studio |
| Изменение физического местоположения базы данных | Оператор ALTER DATABASE |
| Уменьшение размера базы данных | Оператор DBCC SHRINKDATABASE, задача Shrink -> Database в SQL Server Management Studio, доступная через узел базы данных |
| Задание автоматического уменьшения размера базы данных | Системная хранимая процедура sp_dboption, свойства базы данных в SQL Server Management Studio |
| Уменьшение размера файла базы данных | Оператор DBCC SHRINKFILE |
| Добавление файла данных или файла журнала | Оператор ALTER DATABASE, свойства базы данных в SQL Server Management Studio |
| Удаление файла данных или файла журнала | Оператор ALTER DATABASE, свойства базы данных в SQL Server Management Studio |
| Добавление группы файлов | Оператор ALTER DATABASE, свойства базы данных в SQL Server Management Studio |
| Изменение группы файлов по умолчанию | Оператор ALTER DATABASE |
| Изменение параметров базы данных | Оператор ALTER DATABASE, системная хранимая процедура sp_dboption, свойства базы данных в SQL Server Management Studio |
| Переименование | Системная хранимая процедура базы данных sp_renamedb |
| Изменение владельца базы данных | Системная хранимая процедура sp_changedbowner |
Можно задать несколько параметров уровня базы данных, определяющих ее характеристики. Эти параметры доступны для изменения только системному администратору, владельцу базы данных, а также членам стандартных ролей на сервере sysadmin и dbcreator и фиксированной роли в базе данных db_owner. Для каждой базы данных эти параметры уникальны и не влияют на другие базы данных. Задать параметры базы данных можно в конструкции SET оператора ALTER DATABASE, системной хранимой процедуре sp_dboption, а также — в SQL Server Management Studio.
Параметры, общие для сервера, задаются с помощью системной хранимой процедуры sp_configure или SQL Server Management Studio. Параметры уровня соединения определяют посредством оператора SET.
После настройки параметра базы данных автоматически генерируется контрольная точка, благодаря чему изменения вступают в силу немедленно.
В SQL Server существуют пять категорий параметров базы данных, которые перечислены в следующей таблице.
| Тип параметра | Описание |
| Auto | Управляет некоторыми автоматическими режимами и функциями |
| Cursor | Управляет поведением и сферой действия курсора |
| Recovery | Управляет моделью восстановления базы данных |
| SQL | Управляет параметрами совместимости со стандартом ANSI SQL |
| State | Управляет состоянием базы данных (подключена она или отключена). Определяют, кто может подключиться к базе данных, а также находится ли она в режиме «только для чтения» (для контроля за завершением соединений при переходе базы данных из одного состояния в другое могут использоваться специальные конструкции) |
В случае если несистемная база больше не нужна (или она перемещена в другую базу данных или на другой сервер), ее можно удалить. При удалении базы файлы и их данные удаляются с диска на сервере. База данных удаляется навсегда и не может быть восстановлена иначе как со сделанной ранее резервной копии. Удалить системные базы данных (Msdb, Master, Model и Tempdb) невозможно.
После удаления базы данных крайне важно сделать резервную копию базы Master, поскольку при удалении в ней обновляются системные таблицы. При восстановлении базы данных Master у любой базы, удаленной после создания последней резервной копии, останутся ссылки в системных таблицах, что может привести к появлению сообщений об ошибках.
Базу данных удаляют с помощью оператора DROP DATABASE или из консоли в SQL Server Management Studio.
Читайте также
При попытке подключения к серверу БД сначала проверяется, какой метод аутентификации определен для данного пользователя. Если определен Windows NT Authentication Mode, то далее проверяется, имеет ли данный пользователь домена доступ к ресурсу SQL Server, если он имеет доступ, то. [читать подробенее]
Примеры select * from dbo.Authors with (rowlock) delete from dbo.Authors with (rowlock) where code_author = 1 insert into dbo.Authors with (rowlock) (code_author)values(6) Название встроенной процедуры Описание sp_grantlogin – позволяет использовать пользователей или группы ОС для соединения с Microsoft SQL Server™ , используя Windows Authentication. . [читать подробенее]
II. Загрузка в Access базы данных c сервера и работа с ней. Теперь выполним процедуру загрузки удаленной БД и работы с ней: Запускаем программу Access, Выбираем раздел Создать\Проект с существующими данными, Выбрать новое подсоединение к серверу MS SQL Server Открыть базу. [читать подробенее]
ELSE COMMIT TRAN END ROLLBACK TRAN BEGIN END ROLLBACK TRAN BEGIN BEGIN TRAN IF (SELECT COUNT(Поставки.Количество_ед_товара) FROM Товары INNER JOINПоставки ONТовары. ID_товара = Поставки.Товар WHERE Товары.Название_товара = ‘Кофе Ирландский крем’) >=400RETURNUPDATE Продажи SET Цена_ед_товара =. [читать подробенее]
ELSE COMMIT TRAN END ROLLBACK TRAN BEGIN END ROLLBACK TRAN BEGIN BEGIN TRAN IF (SELECT COUNT(Поставки.Количество_ед_товара) FROM Товары INNER JOINПоставки ONТовары. ID_товара = Поставки.Товар WHERE Товары.Название_товара = ‘Кофе Ирландский крем’) >=400RETURNUPDATE Продажи SET Цена_ед_товара =. [читать подробенее]
Управление пользователями базы данных Введение Рассматривается система безопасности, принятая в языке SQL. Излагаются общие правила разграничения доступа. Описываются режимы аутентификации и компоненты структуры безопасности (пользователи, роли баз данных). [читать подробенее]
Реализация баз данных и таблиц MS SQL Server Нормализация схем отношений между таблицами и данными Как же осуществляется нормализация схем отношений между данными и таблицами? Язык нормальных форм констатирует наличие или отсутствие определенных функциональных. [читать подробенее]
Реализация баз данных и таблиц MS SQL Server Нормализация схем отношений между таблицами и данными Как же осуществляется нормализация схем отношений между данными и таблицами? Язык нормальных форм констатирует наличие или отсутствие определенных функциональных. [читать подробенее]
Команды меню Format Этот пункт меню доступен при работе в конструкторе форм, отчетов, программ, текстовых файлов и этикеток. Меню Format (Формат) содержит команды, управляющие характеристиками шрифта, выравниванием текста и объектов, определением интервалов между объектами. [читать подробенее]
Основы оператора SELECT Оператор SELECT позволяет извлекать данные из БД SQL Server и представлять их пользователю в виде одного или нескольких результирующих наборов. Результирующий набор — это данные в табличной форме, полученные в результате исполнения оператора SELECT. Подобно. [читать подробенее]
Как изменить владельца базы данных ms sql
Изменение владельцев баз данных SQL Server 2005, sp_changedbowner
В SQL Server 2005 есть возможность менять владельца базы данных. Производится эта операция при помощи такой же хранимой процедуры sp_changedbowner , что в SQL Server 2000. Пример вызова этой хранимой процедуры может выглядеть так (меняется владелец текущей базы данных):
На графическом экране SQL Server Management Studio поменять владельца базы данных нельзя.
Произвести смену владельца для системных базы данных master , model и tempdb невозможно.
Как изменить владельца базы данных ms sql
Как развернуть базу данных на MS SQL?
Создание информационных баз данных в среде SQL является достаточно простой операцией. От вас не потребуется каких-либо глубоких познаний в данной области, а только наличие программы SQL Server, лучше всего версии 2008 R2.
При помощи обозревателя объектов в запущенном SQL Server подключитесь к нужной вам позиции компонента SQL Database Engine. После этого необходимо выполнить развертку необходимого узла. Запустите базу данных из контекстного меню и выберите команду создания базы данных .присвоив ей наименование и подтвердите операцию. Если вы хотите изменить владельца базы данных, используйте поле с обозначением (…). На вкладке параметров укажите настройки на ваше усмотрение. Параметры самой базы отредактировать можно здесь же.
На вкладке с названием «Группы файлов» выберите вариант добавления ногой файловой группы. Внесите необходимые изменения для каждого добавляемого вами элемента. В расширенных свойствах вы можете добавить непредусмотренные свойства для вашей базы в строках имени и описания. Завершите операцию по созданию базы данных и ее развертку, подтвердите операцию и закройте окна. При возникновении трудностей в работе с программным обеспечением Microsoft SQL Server изучите справочную литературу, которая содержит в себе примеры выполнения стандартных задач.