Базы данных: модели, разработка, реализация
Проектирование реляционных баз данных с использованием декомпозиционного и ER–методов. Вопросы поддержки целостности, защиты информации и параллельной обработки данных. Приложения для работы с базами данных с использованием СУБД Access и языка VBA.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | учебное пособие |
| Язык | русский |
| Дата добавления | 01.03.2011 |
| Размер файла | 211,5 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Второй вид возникает в случае добавления к обоим частям данной ФЗ одного и того же атрибута с целью формирования новой зависимости:
Если А -> В, то А,Z -> B,Z является корректной, но избыточной ФЗ.
Определение транзитивной зависимости и концепции добавления, данные выше, касаются двух приемов удаления избыточных ФЗ из имеющихся. Эти приемы могут быть использованы для уменьшения, модификации исходного набора ФЗ и получения другого, эквивалентного ему набора ФЗ.
Рассмотрим вкратце еще три приема удаления избыточных ФЗ.
Два наиболее простых для понимания приема удаления связаны с объединением и декомпозицией ФЗ, которые определяются следующим образом:
Объединение ФЗ: если А -> В и А -> С, то А -> В,С.
ДекомпозицияФЗ: если А -> В,С, то А -> В и А -> С.
Пятая разновидность избыточности называется псевдотранзитивностью.
Если X -> Y и Y,W -> Z, то X,W -> Z является избыточной в силу псевдотранзитивности. Этот тип избыточности возникает в тех случаях, когда в получаемых ФЗ обнаруживаются детерминанты. При обнаружении псевдотранзитивной зависимости ее необходимо удалить.
Минимальное покрытие
Набор не избыточных ФЗ, полученный путем удаления всех избыточных ФЗ из исходного набора с помощью приемов удаления, называетсяминимальным покрытием.
К сожалению, минимальное покрытие не всегда является уникальным, поскольку порядок, в котором осуществляется процедура удаления избыточных ФЗ, может оказать влияние на минимальное покрытие.
Рекомендуется избыточные ФЗ удалять по одной, каждый раз заново анализируя новый набор на предмет присутствия в нем избыточных ФЗ.
Эта процедура завершается, как только не останется ни одной избыточной ФЗ. Оставшийся набор является минимальным покрытием.
Модернизированный алгоритм проектирования БД
С учетом изложенного алгоритм декомпазиционного проектирования БД включает следующие этапы:
1. Построение универсального отношения для БД.
2.Определение всех ФЗ, существующих между атрибутами универсального отношения.
3.Удаление всех избыточных ФЗ из исходного набора ФЗ с целью получения минимального покрытия. Эта процедура проводится путём поочередного удаления избыточных ФЗ с последующей проверкой получаемого на каждом шаге набора ФЗ на наличие хотя бы одной избыточной ФЗ.
4. Использование ФЗ из минимального покрытия для декомпозиции универсального отношения в набор НФБК -отношений.
5.Определение того, находятся ли полученные отношения в НФБК. Если да, то проектирование завершается, если нет, то отношения не находящееся в НФБК должны быть разложены на два отношения.
5.Повторение шага 5 для каждого нового отношения, полученного в результате декомпозиции. Проектирование завершается, когда все отношения будут находиться в НФБК.
7. Если может быть получено более чем одно минимальное покрытие, то осуществляется сравнение результатов, полученных на основе различных минимальных покрытий, с целью определения варианта, лучше других отвечающего требованиям пользователя.
При использовании алгоритма декомпозиции следует помнить о нежелательности проекции, порождаемой ФЗ, у которой зависимостная часть является детерминантом другой ФЗ; также повышенное внимание требуется в тех случаях, когда зависимостная часть ФЗ зависит более чем от одного детерминанта. В любом из этих случаев может быть утеряна ФЗ из БД. Если в процессе декомпозиции достигнуто состояние, в котором проецирование, не влекущее за собой потерь ФЗ, становится невозможным, проектировщик должен будет сделать выбор из двух альтернатив: 1 - выбор оставшихся ФЗ и создание одного отношения для каждых детерминанта и набора зависящих от него атрибутов; 2 - изменение порядка ранее проведенных декомпозиций, ведь алгоритм проектирования не ведет к единому решению.
1.6 Метод ER - проектирования
Если число атрибутов проектируемой БД превышает 20, декомпозиционный метод проектирования становится излишне громоздким. В этом случае следует обратить внимание на другие методы. Один из таких методов называется "сущность-связь" или ER - методом. Он отличается от метода декомпозиции тем, что ФЗ привлекаются не на начальном, а на конечном этапе проектирования.
1.6.1 Сущности и связи
Представление о методе можно получить с помощью специально подобранного примера. Предположим, что проектируется БД, предназначенная для хранения информации о преподавателях института и о тех дисциплинах, которые они читают. Двумя главными объектами, или сущностями, представляющими в данном случае интерес, являются ПРЕПОДАВАТЕЛЬ и ДИСЦИПЛИНА. Эти две сущности соотносятся с помощью связи ЧИТАЕТ, что позволяет нам сказать ПРЕПОДАВАТЕЛЬ ЧИТАЕТ ДИСЦИПЛИНА.
Это утверждение может быть представлено графически.
Связь. Связь представляет собой соединение между двумя или более сущностями. При поиске связей в основном следует полагаться на то обстоятельство, что связь обычно выражается глаголом. Типичными примерами связей между двумя сущностями являются: служащие РАБОТАЮТ в отделах, студенты ИЗУЧАЮТ учебные дисциплины, рабочие ОБСЛУЖИВАЮТ механизмы и т. д.
Тесно связано с предыдущими третье важное понятие, обсуждавшиеся ранее, а именно атрибут. Атрибут, есть свойство сущности. Например, атрибутами, могущими быть свойствами сущности ДИСЦИПЛИНА, являются: номер дисциплины, семестр в котором она преподавалась, предыдущая дисциплина, на которую она базируется, число часов на дисциплину и т.д. Атрибутами сущности ПРЕПОДАВАТЕЛЬ являются: номер - преподавателя, ученая степень, ученое звание, стаж работы и т. д.
Возвращаясь к рис. 6.1 и 6.2 отметим, что на диаграмме ER - экземпляров названия всех сущностей помещены над экземплярами этих сущностей и в них использованы прописные буквы, в то время как каждый экземпляр сущности идентифицируется значениями атрибута. Так ДИСЦИПЛИНА является сущностью, а Д1 - конкретным экземпляром сущности. Связь также именуется, и ее название, составленное из прописных букв, размещается над экземплярами связи, при этом экземпляр каждой отдельной связи специфицируется линией между теми двумя экземплярами сущностей, которые эта связь соединяет. Экземпляр связи между Д2 и П3, например, означает, что преподаватель с номером П3 читает дисциплину с номером Д2.
В некоторых случаях может понадобиться набор атрибутов для идентификации каждого экземпляра сущности. Атрибут, или набор атрибутов, используемый для идентификации экземпляра сущности, называется ключом сущности. Каждый экземпляр связи однозначно определяется набором ключей сущностей, соединяемых этой связью.
При ER-методе на начальном этапе проектирования естественными требуемыми атрибутами являются те, которые необходимы для формирования ключей сущностей. Другие атрибуты вместе с определенными для них ФЗ потребуются на более поздних этапах проектирования.
На диаграммах ER - типа (рис. 6.2.) сущности представляются в виде прямоугольников, а связи в виде ромбов. Ниже каждой сущности размещается атрибут, или набор атрибутов, являющийся ключом сущности для данной сущности. Значение цифры "1" на диаграмме и маленьких сплошных кружков будут обсуждены далее.
В большинстве случаев для определения набора отношений проектируемой БД используются диаграммы ER - типа, а не диаграммы экземпляров.
1.6.2 Переход от диаграмм ER - типа к отношениям
Связь ЧИТАЕТ, существующая между сущностями ПРЕПОДАВАТЕЛЬ и ДИСЦИПЛИНА называется бинарной, поскольку она связывает только две сущности. Бинарные связи встречаются наиболее часто.
Рассмотрим, как с использованием диаграммы ER-типа можно получить отношения, служащие основой построения БД.
Общий подход к построению БД с использованием ER-метода состоит прежде всего в построении диаграммы ER-типа, включающую в себя все сущности и связи, важные с точки зрения интересов пользователя.
Второй шаг в процессе проектирования состоит в построении набора предварительных отношений и указании предполагаемого первичного ключа для каждого отношения.
Последний шаг состоит в подготовке списка всех представляющих интерес атрибутов (тех из них, которые не были уже перечислены в диаграмме ER-типа в качестве ключей сущности) и включение каждого из этих атрибутов в одно из предварительных отношений с тем условием, чтобы эти отношения находились в НФБК.
На этом последнем шаге для каждого отношения должны быть определены межатрибутные ФЗ, с помощью которых проверяется соответствие отношений НФБК. Если полученные в итоге отношения не находятся в НФБК, то к ним необходимо применить операцию декомпозиции, с последующей проверкой полученных отношений на нахождение в НФБК.
Если же некоторым атрибутам не находятся логически обоснованных мест в предварительных отношениях, то в этих случаях необходимо пересмотреть ER-диаграммы на предмет устранения возникших затруднений.
Предварительные отношения для бинарных связей степени 1:1
Предварительные отношения для данной бинарной связи могут быть получены путем просмотра нескольких логических альтернатив и выбора среди них наиболее подходящей. Перечень общих правил генерации отношений из диаграмм ER-типа можно получить, опираясь на класс принадлежности и степень связи как на определяющие факторы. С целью упрощения вывода этих правил будет использована ситуация ПРЕПОДАВАТЕЛЬ ЧИТАЕТ ДИСЦИПЛИНА (обсуждавшаяся ранее) вместе со ссылками на приведенные диаграммы. Обсуждение будет ограничено случаями, в которых степень бинарных связей равно 1:1.
При попытке определить как много отношений необходимо для размещения информации, содержащейся в бинарных связях степени 1:1, подобных приведенным на диаграммах ER-типа (см. рис.6.4), простейшим решением, на которое можно надеяться, является необходимость одного отношения. Пусть это отношение называется ПРЕПОДАВАТЕЛЬ и все атрибуты помещаются в это одно отношение. На рис.6.5 приведен экземпляр такого отношения в том случае, когда класс принадлежности является обязательным для обеих сущностей (см. рис.6.3 г и 6.4 г). В этом отношении сущность ПРЕПОДАВАТЕЛЬ была дополнена двумя типичными атрибутами: фамилия преподавателя (пфам) и телефон-преподавателя (птел). Один атрибут добавлен к сущности ДИСЦИПЛИНА: название дисциплины.
1.6.3 Дополнительные конструкции, используемые в ER - методе
Не все ситуации можно свести к бинарным связям. Поэтому представляет интерес дополнительные конструкции, позволяющие решать задачи при наличии связей более высокого порядка.
Необходимость связей более высокого порядка
Спроектируем БД, предназначенную для хранения информации о рабочих и станках, которые ими обслуживаются. Каждый рабочий обслуживает только один станок. Представляющими интерес атрибутами являются: фамилия рабочего (рфам), номер цеха (нцех), тарифная ставка (тстав), номер станка (сном), тип станка (стип), основной тип деталей, обрабатываемых на станке (дтип) и материал детали (мдет).
При составлении диаграмм учитывалось, что все рабочие имеют работу, фамилии рабочих уникальны, некоторые станки рабочими не обслуживаются.
Т.к. степень связи равна 1:1 и класс принадлежности одной сущности является обязательным, а другой - нет, то используется правило 2 при генерации предварительных отношений. В результате получаем отношения: РАБОЧИЙ (рфам.... сном) и СТАНОК (сном....).
Остается найти место атрибутам, не используемым в качестве ключей сущности: нцех, тстав, стип, дтип. Атрибуты нцех и тстав находят свое место в отношении РАБОЧИЙ, т.к. они содержат информацию о рабочих; стип, дтип и мдет помещаются в отношение СТАНОК, т.к. в них содержится информация о станках и деталях, на них обрабатываемых. Таким образом, предлагаются следующие отношения:
В основе рассмотренного примера лежит необходимость хранения информации о рабочих; станках, обслуживаемых рабочим; типах деталей, обрабатываемых на этих станках. Предположим, что нам необходимо знать, какой-тип детали предпочитает изготавливать тот или иной рабочий. Если посмотреть на диаграмму экземпляров, изображенную на рис. 6.13, а) то может показаться естественным заключение о том, что раз рабочий Р1 обслуживает станок С1, на котором обрабатываются детали 2Т и 1Т, то следовательно Р1 любит изготавливать детали 2Т и 1Т. Это может быть правдой, а может и не быть.
Если связь между сущностями РАБОЧИЙ и ДЕТАЛЬ существует, то эта связь, назовем ее ПРЕДПОЧИТАЕТ, должна быть представлена на диаграмме ER - экземпляров, как это показано на рис. 6.15.
Использование ролей
В некоторых случаях одних сущностей и связей может оказаться недостаточно для полноценного моделирования организации.
Одна из таких ситуаций возникает тогда, когда экземпляры некоторой сущности должны играть разные роли в деятельности организации. В качестве примера положим, что для небольшого предприятия поставщика автомобилей необходимо хранить информацию о производственном персонале: двух категориях служащих - мастерах и сборщиках. Мастера получают финансированный оклад, в то время как у сборщиков почасовая оплата.
Предполагается, что ни один мастер не руководит другим мастером, ни один мастер не является сборщиком и ни один сборщик не является мастером.
1.6.4 Проверка отношений на завершающейся фазе проектирования
После завершения разработки НФБК- отношений, рассматриваемых уже в качестве окончательного проекта, полученный набор необходимо проконтролировать на предмет наличия не выявленных проблем.
1. Составляются списки ФЗ для каждого отношения. Одна и та же ФЗ не должна появляться более чем в одном отношении. Если таковые имеются, то их необходимо удалить.
2. Осуществляется проверка на присутствие избыточных отношений. Отношение является избыточным, если а) - все атрибуты в избыточном отношении могут быть найдены в другом отношении проектного набора; б) - все атрибуты в избыточном отношении могут быть найдены в отношении, которое может быть получено из других отношений предложенного проектного набора с помощью серии операций СОЕДИНЕНИЕ над этими отношениями. Если устанавливается избыточность отношения, его следует исключить из проектного набора.
Для примера, иллюстрирующего первый тип избыточности, полагаем, что набор проектных отношений имеет вид:
R1(A,B)
R2(B,C,Y,Z)
R3(A,B,K)
Отношение R1 является избыточным, т.к. все его атрибуты присутствуют в отношении R3.
Для иллюстрации избыточности второго типа положим, что предлагаемый проектный набор имеет вид:
R1(A,C,X)
R3(D,K,F)
R5(D,E,G,H)
R7(A,B,D)
R8(A,B,E,G)
Отношение R8 является избыточным, т.к. применение операции СОЕДИНЕНИЕ к R5 и R7 (общим атрибутом является D) даст отношение R9(A,B,E,D,G,H), которое содержит все атрибуты, присутствующие в R8.
3. Рассмотрение отношений с практической точки зрения. Изучается характер использования отношений в конструируемой БД и определяется будут ли они поддерживать те типы запросов и операции обновления, которые предполагается использовать
4. При использовании декомпозиционного метода проектирования набор ФЗ, полученный в результате проектирования, должен в точности совпадать с набором, присутствующим в минимальном покрытии, полученном перед началом декомпозиции.
1.7 Другие нормальные формы
Существует 6 нормальных форм, в которых может находится отношение: первая (1НФ), вторая (2НФ), третья (3НФ), НФБК, четвертая (4НФ) и пятая (5НФ). О первой нормальной и НФБК мы уже говорили. Следует отметить, что если отношение находится в N - форме, то оно находится во всех формах до N-1.
Таким образом, если отношение находится в НФБК, то оно находится и в 1НФ и во 2НФ и в НФБК. Однако для полноты картины рассмотрим 2НФ и 3НФ.
Отношение находится во второй нормальной форме тогда, когда оно находится в первой нормальной форме и не содержит неполных функциональных зависимостей не первичных атрибутов от атрибутов первичного ключа.
Рассмотрим отношение, моделирующее сдачу текущей сессии студентами, живущими в общежитии.
R(Сном, Сфам, Кном, Тном, Дисциплина, Оценка).
Здесь первичным ключом являются атрибуты <Сном, Дисциплина>, а атрибуты Сфам, Кном и Тном зависят только от части первичного ключа Сном, т.е. в данном случае в отношении имеется неполная ФЗ. Для приведения данного отношения ко второй нормальной форме необходимо разбить его на два отношения : R1(Сном, Сфам, Кном, Тном) и R2(Сном, Дисциплина, Оценка).
В исходном отношении R присутствуют те аномалии, о которых мы говорили ранее. В полученном наборе отношений аномалии вставки и удаления отсутствуют, но присутствует аномалия обновления.
Отношение находится в третьей нормальной форме тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей.
Рассмотрим полученное в предыдущем примере отношение R1(Сном, Сфам, Кном, Тном). Это отношение находится во второй нормальной форме, однако в нем имеется транзитивная зависимость Сном -> Тном.
Для приведения этого отношения к третьей нормальной форме необходимо его разбить на два отношения R3(Сном, Сфам, Кном) и R4(Сном, Тном). При таком представлении отношений аномалия обновления не исчезла.
Рассмотрим 4НФ и 5НФ.
Ранее рассматривались случаи ФЗ, когда каждому значению детерминанта соответствовало только одно значение зависимого от него атрибута. Однако на практике можно встретить случаи, когда одному значению некоторого атрибута соответствует устойчиво постоянное множество значений другого атрибута.
Рассмотрим конкретную ситуацию. Пусть дано отношение, которое моделирует предстоящую сдачу экзаменов в сессии. Допустим оно имеет вид: R(Группа, Сном, Дисциплина).
Перечень дисциплин, которые должен сдавать студент, однозначно определяется не его номером, а номером группы (т. е. специальностью, на которой он учится).
|
Группа |
Сном |
Дисциплина |
|
|
1409 |
111 |
БД |
|
|
1409 |
111 |
АПП |
|
|
1409 |
112 |
БД |
|
|
1409 |
112 |
АПП |
|
|
1410 |
222 |
БД |
|
|
1410 |
222 |
АПП |
|
|
1410 |
223 |
БД |
|
|
1410 |
223 |
АПП |
|
В данном отношении существуют две многозначные зависимости: Группа ->> Сном и Группа ->> Дисциплина.
Это означает, что каждой группе однозначно соответствует перечень дисциплин по учебному плану и номер группы определяет список студентов, которые в этой группе учатся.
Если в БД использовать отношение R, то в нее нельзя поместить информацию о новой группе и ее учебном плане - перечне дисциплин, которые должна пройти группа до тех пор, пока в нее не будут зачислены студенты. При изменении перечня дисциплин по учебному плану, например, при добавлении новой дисциплины, внести эти изменения в отношение для всех студентов, занимающихся в данной группе, весьма затруднительно. С другой стороны, если необходимо добавить студента в уже существующую группу, то потребуется добавить множество кортежей, соответствующих перечню дисциплин для данной группы. Наконец, если нужно изменить название дисциплины, то это необходимо сделать для каждого студента. Такая же ситуация будет иметь место при удалении дисциплины из БД. Эти аномалии модификации отношений как раз и связаны с наличием многозначных зависимостей.
В общем случае в отношении R( А, В, С) существует многозначная зависимость А ->> В в том случае, когда существует многозначная зависимость А ->>С.
Дальнейшая нормализация отношения, подобного рассматриваемому, основывается на теореме Фейджина.
Отношение R(А, В, С) можно спроецировать без потерь в отношение R1(А, В) и R2(А, С) в том случае, когда существует многозначная зависимость А ->> В|C (что равнозначно наличию двух зависимостей А ->> В и А ->>С).
Под проецированием без потерь понимается такой способ декомпозиции отношения путем применения операции проекции, при котором исходное отношение полностью и без избыточности восстанавливается путем естественного соединения полученных отношений.
Отношение R находится в четвертой нормальной форме в том случае, если в случае существования многозначной зависимости А ->> В все остальные атрибуты R функционально зависят от А.
В рассмотренном примере можно произвести декомпозицию исходного отношения в два отношения: R1( Группа, Сном) и R2(Группа, Дисциплина)
|
Группа |
Сном |
Группа |
Дисциплина |
|
|
1409 |
111 |
1409 |
БД |
|
|
1409 |
112 |
1409 |
АПП |
|
|
1410 |
222 |
1410 |
БД |
|
|
1410 |
223 |
1410 |
АПП |
|
Оба эти отношения находятся в 4НФ и свободны от отмеченных аномалий. Операции модификации теперь упрощаются: добавление нового студента связано с добавлением всего одного кортежа в отношение R1, а добавление новой дисциплины выливается в добавление по одному кортежу для каждой группы специальности в отношение R2. Кроме того, в отношении R2 можно хранить любое количество групп с определенным перечнем дисциплин, в которые пока еще не зачислены студенты. Наконец, если нужно изменить название дисциплины или удалить определенную дисциплину, то это нужно сделать несколько раз по числу групп специальности, в отличии от исходного случая, когда это нужно было делать по каждому студенту.
Последней нормальной формой является пятая нормальная форма, которая связана с анализом нового вида зависимостей, зависимостей «проекция соединения» (project - join зависимости, обозначаемые как PJ - зависимости).
5НФ редко используется на практике. В большой степени она является теоретическим исследованием. Очень тяжело определить само наличие зависимостей «проекция соединения», потому что утверждение о наличии такой зависимости делается для всех возможных состояний БД, а не только для текущего экземпляра отношения R. Однако знание о возможном наличии подобных зависимостей, даже теоретически, необходимо.
2. Специальные аспекты работы с базами данных
2.1 Защита данных в базе
2.1.1 Общие вопросы защиты данных
Термин “защита данных” означает, во-первых, предупреждение несанкционированного или случайного доступа к данным, их изменения или разрушений со стороны пользователей. И во-вторых, предупреждение изменения или разрушения данных при сбоях аппаратных и программных средств и ошибках в работе пользователей.
Защита данных обеспечивает их безопасность и секретность. Эти две функции тесно связаны между собой и для их реализации используются одни и те же технические методы защиты данных в БД. Но между этими функциями существует и принципиальное различие. Под функцией безопасности понимается защита данных от непреднамеренного доступа к данным и .возможности их искажения со стороны пользователей, а также при сбоях в аппаратуре или программных средствах. Поэтому обеспечение безопасности это внутренняя задача поскольку связана с его нормальным функционированием. Под функцией секретности понимается защита данных от преднамеренного доступа пользователей или посторонних лиц. Обеспечение секретности требует разделение всей хранимой в БД информации на доступные данные и данные, которые должны использоваться конфиденциально (т.е. либо сами содержат секретную информацию, либо ее можно получить из них с помощью специальной алгоритмической обработки). Решение этого вопроса выходит за рамки БД и находится в компетенции юридических органов или администрации предприятия, для которого создается Б Д.
Рассмотрим техническую сторону методов обеспечения защиты данных в базе.
Можно выделить уровни доступа к БД для различных категорий пользователей; 1) неограниченный доступ ко всем отношениям в БД и их объектам; 2) неограниченный доступ к группе отношений и их объектам; 3) ограниченный доступ к группе отношений и их объектам.
На уровне отношения различают следующие уровни доступа:
1) неограниченный доступ ко всему отношению для всех типов операций;
2) запрет на доступ к любым частям отношения для всех типов операций;
3) доступ к любой части отношения, но без права изменения его содержимого;
4) доступ к любой части отношения, но с правом изменения значений только для атрибутов A1, А2, . . Аn;
5) неограниченный доступ только к одному кортежу отношения для всех типов операций;
5) доступ только к одному кортежу отношений без права изменения содержимого этого кортежа;
7) неограниченный доступ только к атрибутам A1, А2, . . An отношения для всех типов операций и запрет доступа к остальным атрибутам отношения;
8) доступ только к атрибутам А1, А2, . . Аn отношения без права изменения их значений и запрет доступа к остальным атрибутам отношения;
9) доступ только к атрибутам A1,A2,…An отношения с правом изменения значений только для атрибутов A1..Ap, где (A1 . . Ap)(A1, А2, ... An) и запрет доступа к остальным атрибутам отношения;
10) доступ в соответствии с пунктами 1,3,4,5,5,7,8,9, но с ограничением по интервалу времени (с t1 no t2);
11) доступ в соответствии с пунктами 1,3,4,5,5,7,8,9, но с разрешением изменения значений атрибутов только в случае выполнения условий F1, F2, . . Fn соответственно для значений атрибутов A1,А2,..An (например, если значение атрибута не превышает некоторой величины Z);
12) разрешение права применения вычислительных операторов (суммирование, вычитание и т.п.) к атрибутам А1,А2,..Аn, без права доступа к этим атрибутам или изменения их значений.
Приведенный список уровней доступа показывает требуемый диапазон работы и необходимую гибкость системы зашиты данного общего назначения. В настоящее время нет реальных систем, в которых были бы реализованы все эти возможности для защиты данных.
Поскольку большинство СУБД работает под уравнением операционных систем ЭВМ, для защиты данных в БД широко применяются средства защиты, представляемые операционными системами.
Рассмотрим основные методы и приемы зашиты данных.
Идентификация пользователя. Перед началом сеанса с системой пользователи должны идентифицировать себя и подтвердить подлинность своей идентификации, т.е. что они именно те лица, за которых себя выдают. Для особо важной информации эти два шага могут многократно повторяться. Процесс идентификации пользователя выполняется с помощью либо системного идентификационного номера пользователя, либо номера терминала, запросившего сеанс работы. В последнем случае необходимо использовать организационные меры, обеспечивающие возможность работы с определенного терминала только определенных лиц. Процесс подтверждения подлинности представляет собой обмен между пользователем и системой информацией, известной только системе и пользователю. В простейшем случае процесс подтверждения подлинности может отсутствовать, и система защиты использует только процесс идентификации пользователя. Подтверждение подлинности реализуется специальной процедурой, обычно не сложной, но характеризующейся очень низкой вероятностью ее раскрытия. Это может быть одноразовые пароли, ответы на некоторые вопросы или реализация некоторых алгоритмов.
Управление доступом. В ряде случаев информация о составе разрешенных пользователю операций оказывается недостаточной для решения вопроса о допустимости выполнения этих операций с конкретными данными. Поэтому каждое групповое данное должно иметь связанный с ним набор ограничений доступа. Этот набор ограничений содержит: условие, которому должен удовлетворять пользователь, чтобы иметь доступы к групповому данному; пароль, предъявляемый при выборке некоторых комбинаций данных из группового данного; пароль, предъявляемый при модификации этих данных, и т.п.
В общем случае для решения вопроса о доступе пользователя к данным в составе СУБД должна быть специальная программа, проверяющая запрос пользователя на основании его паспорта, набора ограничений и конкретных значений данных в БД и решающая вопрос о разрешении или запрещении доступа. Алгоритм подобной программы базируется на аксиоме безопасности и реализует различные проверки.
Аксиома безопасности. Если комбинация атрибутов А доступна (запрещена) пользователю Х в зависимости от условия В, то каждая подкомбинация А также доступна (запрещена) пользователю Х по условию В.
Состав проварок может быть, например, следующим.
1. Все ли отношения, упомянутые в запросе, доступны пользователю Х?
2. Все ли объекты, упомянутые в запросе, доступны пользователю Х ?
3. Все ли комбинации атрибутов, упомянутые в запросе, доступны пользователя X?
4. Задано ли квалифицирующее выражение, которое ограничивает для пользователя Х диапазон значений атрибутов, и если да, то лежат ли их значения внутри диапазона, доступного для X?
Если в результате проверок будет получен отрицательный ответ, то программа информирует пользователя об отклонении его запроса.
Защита данных при статической обработке. Кроме обычных проблем предотвращения несанкционированного доступа к БД для статических процедур существуют свои специфические проблемы защиты данных.
Первый подход защиты данных заключается в том, что если и не исключить полностью возможность раскрытия индивидуальных данных, то по крайней мере сделать эту возможность достаточно трудной.
Второй подход заключается в следующем. Если ключ записи состоит из Х полей и в запросе допускается специфицировать не более Y (Y<Х) полей ключа (т.е. выполняется поиск по частичному соответствию ключа), то никакая статическая функция, использующая только операции сложения, вычитания, умножения и деления, не позволит определить значение данного в конкретной записи.
Физическая защита. Подходы, рассмотренные выше, недостаточны для защиты БД от лиц, желающих ее использовать в обход системы. Примером обхода системы является физическое извлечение части БД; похищение флоппи дисков или винчестера, контроль передачи по линии связи между удаленным терминалом, за которым работает истинный пользователь, и системой и т.п.
Основная мера защиты при подобных ситуациях - использование специальных методов кодирования данных. Один из простейших методов - перекомпоновка символов в кортеже, записи, сообщении. Другой метод заключается в замене символа (или группы символов) другим (или группой символов) этого же либо другого алфавита и др. Физическая защита связана также с защитой данных от сбоев в аппаратных и программных средствах. В этом случае используется средства ОС - хранение поколений данных, формирование контрольных точек и выполнение при необходимости рестарта, ведение системных журналов и т.п.
2.1.2 Реализация защиты данных в различных системах
В современных СУБД поддерживается один из двух наиболее общих подходов к вопросу обеспечения безопасности данных: избирательный подход и обязательный подход. В обоих подходах единицей данных или «объектом данных», для которых должна быть создана система безопасности, может быть как вся база данных целиком, так и любой объект внутри базы данных.
Эти два подхода отличаются следующими свойствами:
- В случае избирательного управления некоторый пользователь обладает различными правами (привилегиями или полномочиями) при работе с данными объектами. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту. Избирательные права характеризуются значительной гибкостью.
- В случае обязательного управления, наоборот, каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. При таком подходе доступом к определенному объекту данных обладают только пользователи с соответствующим уровнем допуска.
Для реализации избирательного принципа предусмотрены следующие методы:
- В базу данных вводится новый тип объектов БД -- это пользователи. Каждому пользователю в БД присваивается уникальный идентификатор. Для дополнительной защиты каждый пользователь кроме уникального идентификатора снабжается уникальным паролем, причем если идентификаторы пользователей в системе доступны системному администратору, то пароли пользователей хранятся чаще всего в специальном кодированном виде и известны только самим пользователям.
- Пользователи могут быть объединены в специальные группы пользователей. Один пользователь может входить в несколько групп. Вводится понятие группы PUBLIC, для которой должен быть определен минимальный стандартный набор прав. По умолчанию предполагается, что каждый вновь создаваемый пользователь, если специально не указано иное, относится к группе PUBLIC.
- Привилегии или полномочия пользователей или групп -- это набор действий (операций), которые они могут выполнять над объектами БД.
- В последних версиях ряда коммерческих СУБД появилось понятие «роли» Роль -- это поименованный набор полномочий. Существует ряд стандартных ролей, которые определены в момент установки сервера баз данных. И имеется возможность создавать новые роли, группируя в них произвольные полномочия. Введение ролей позволяет упростить управление привилегиями пользователей, структурировать этот процесс. Кроме того, ведение ролей не связано с конкретными пользователями, поэтому роли могут быть определены и сконфигурированы до того, как определены пользователи системы.
- Пользователю может быть назначена одна или несколько ролей.
- Объектами БД, которые подлежат защите, являются все объекты, хранимые в БД таблицы, представления, хранимые процедуры и триггеры. Для каждого типа объектов есть свои действия, поэтому для каждого типа объектов могут быть определены разные права доступа.
На самом элементарном уровне концепции обеспечения безопасности баз данных исключительно просты. Необходимо поддерживать два фундаментальных принципа: проверку полномочий и проверку подлинности (аутентификацию).
Проверка полномочий основана на том, что каждому пользователю или приложению информационной системы соответствует набор действий, которые он может выполнять по отношению к определенным объектам. Проверка подлинности означает достоверное подтверждение того, что пользователь или приложение, пытающийся выполнить санкционированное действие, действительно тот, за кого он себя выдает.
Система назначения полномочий имеет в некотором роде иерархический характер. Самыми высокими правами и полномочиями обладает системный администратор или администратор сервера БД. Традиционно только этот тип пользователей может создавать других пользователей и наделять их определенными полномочиями.
СУБД в своих системных каталогах хранит как описание самих пользователей, так и описание их привилегий по отношению ко всем объектам.
Далее схема предоставления полномочий строится по следующему принципу. Каждый объект в БД имеет владельца -- пользователя, который создал данный объект. Владелец объекта обладает всеми правами-полномочиями на данный объект, в том числе он имеет право предоставлять другим пользователям полномочия по работе с данным объектом или забирать у пользователей ранее предоставленные полномочия.
В СУБД, поддерживающих однобазовая архитектуру (например, Oracle), вводится понятие подсхемы -- части общей схемы БД и вводится пользователь, имеющий доступ к подсхеме.
В стандарте SQL не определена команда создания пользователя, но практически во всех коммерческих СУБД создать пользователя можно не только в интерактивном режиме, но и программно с использованием специальных хранимых процедур. Однако для выполнения этой операции пользователь должен иметь право на запуск соответствующей системной процедуры.
Управление доступом в SQL
В стандарте SQL определены два оператора: GRANT и REVOKE предоставления и отмены привилегий соответственно.
Оператор предоставления привилегий имеет следующий формат:
GRANT {<список действий> | ALL PRIVILEGES }
ON <имя_объекта>
ТО {<имя_пользователя> | PUBLIC }
[WITH GRANT OPTION ]
Здесь список действий определяет набор действий из обще допустимого перечня действий над объектом данного типа.
Параметр ALL PRIVILEGES указывает, что разрешены все действия из допустимых для объектов данного типа.
<имя_объекта> -- задает имя конкретного объекта: таблицы, представления, хранимой процедуры, триггера.
<имя_пользователя> или PUBLIC определяет, кому предоставляются данные привилегии.
Параметр WITH GRANT OPTION является необязательным и определяет режим, при котором передаются не только права на указанные действия, но и право передавать эти права другим пользователям. Передавать права в этом случае пользователь может только в рамках разрешенных ему действий.
Рассмотрим пример, пусть у нас существуют три пользователя с абсолютно уникальными именами user1, user2 и user3. Все они являются пользователями одной БД.
Userl создал объект Tab1, он является владельцем этого объекта и может передать права на работу с эти объектом другим пользователям. Допустим, что пользователь user2 является оператором, который должен вводить данные в Tab1 (например, таблицу новых заказов), а пользователь user3 является менеджером отдела, который должен регулярно просматривать введенные данные.
Для объекта типа таблица полным допустимым перечнем действий является набор из четырех операций: SELECT, INSERT, DELETE, UPDATE. При этом операция обновления может быть ограничена несколькими столбцами.
Общий формат оператора назначения привилегий для объекта типа таблица будет иметь следующий синтаксис:
GRANT {[SELECT][.INSERT][.DELETE][.UPDATE
(<список столбцов>)]} ON <имя_таблицы>
TO {<имя_пользователя>| PUBLIC }
[WITH GRANT OPTION ]
В рассматриваемом случае необходимо выполнить следующие назначения:
GRANT INSERT
ON Tab1
TO user2
GRANT SELECT
ON Tab1
TO user3
Эти назначения означают, что пользователь user2 имеет право только вводить новые строки в отношение Tab1, а пользователь user3 имеет право просматривать все строки в таблице Tab1.
При назначении прав доступа на операцию модификации можно уточнить, значение каких столбцов может изменять пользователь. Допустим, что менеджер отдела имеет право изменять цену на предоставляемые услуги. Предположим, что цена задается в столбце SENA таблицы Tab1. Тогда операция назначения привилегии пользователю user3 может измениться и выглядеть следующим образом:
GRANT SELECT, UPDATE (SENA)
ON Tab1
TO user3
Если наш пользователь user1 предполагает, что пользователь user4 может его замещать в случае его отсутствия, то он может предоставить этому пользователю все права по работе с созданной таблицей Tab1.
GRANT ALL PRIVILEGES
ON Tab1
TO user4
WITH GRANT OPTION
В этом случае пользователь user4 может сам назначать привилегии по работе с таблицей Tab1 в отсутствие владельца объекта пользователя user1. Поэтому в случае появления нового оператора пользователя user5 он может назначить ему права на ввод новых строк в таблицу командой:
GRANT INSERT
ON Tab1
TO user5
Если при передаче полномочий набор операций над объектом ограничен, то пользователь, которому переданы эти полномочия, может передать другому пользователю только те полномочия, которые есть у него, или часть этих полномочий. Поэтому если пользователю user4 были делегированы следующие полномочия:
GRANT SELECT, UPDATE, DELETE
ON Tab1
TO user4
WITH GRANT OPTION
то пользователь user4 не сможет передать полномочия на ввод данных пользователю user5, потому что эта операция не входит в список разрешенных для него самого.
Кроме непосредственного назначения прав по работе с таблицами эффективным методом защиты данных может быть создание представлений, которые будут содержать только необходимые столбцы для работы конкретного пользователя и предоставление прав на работу с данным представлением пользователю.
Так как представления могут соответствовать итоговым запросам, то для этих представлений недопустимы операции изменения, и, следовательно, для таких представлений набор допустимых действий ограничивается операцией SELECT. Если же представления соответствуют выборке из базовой таблицы, то для такого представления допустимыми будут все 4 операции- SELECT, INSERT, UPDATE и DELETE.
Для отмены ранее назначенных привилегий в стандарте SQL определен оператор REVOKE. Оператор отмены привилегий имеет следующий синтаксис:
REVOKE {<список операций>| ALL PRIVILEGES}
ON <имя_объекта>
FROM {<список пользователей | PUBLIC }
(CASCADE | RESTRICT }
Параметры CASCADE или RESTRICT определяют, каким образом должна производиться отмена привилегий. Параметр CASCADE отменяет привилегии не только пользователя, который непосредственно упоминался в операторе GRANT при предоставлении ему привилегий, но и всем пользователям, которым этот пользователь присвоил привилегии, воспользовавшись параметром WITH GRANT OPTION.
Например, при использовании операции
REVOKE ALL PRIVILEGES
ON Tab1
TO user4 CASCADE
будут отменены привилегии и пользователя user5, которому пользователь user4 успел присвоить привилегии.
Параметр RESTRICT ограничивает отмену привилегий только пользователю, непосредственно упомянутому в операторе REVOKE. Но при наличии делегированных привилегий этот оператор не будет выполнен.Так, например, операция:
REVOKE ALL PRIVILEGES
ON Tab1
TO user4 RESTRICT
не будет выполнена, потому что пользователь user4 передал часть своих полномочий пользователю user5.
Посредством оператора REVOKE можно отобрать все или только некоторые из ранее присвоенных привилегий по работе с конкретным объектом. При этом из описания синтаксиса оператора отмены привилегий видно, что можно отобрать привилегии одним оператором сразу у нескольких пользователей или у целой группы PUBLIC.
Поэтому корректным будет следующее использование оператора REVOKE
REVOKE INSERT
ON Tab1
TO user2, user4 CASCADE
При работе с другими объектами изменяется список операций, которые используются в операторах GRANT и REVOKE.
По умолчанию действие, соответствующее запуску (исполнению) хранимой процедуры, назначается всем членам группы PUBLIC.
Если необходимо изменить это условие, то после создания хранимой процедуры необходимо записать оператор REVOKE
REVOKE EXECUTE
ON COUNT_EX
TO PUBLIC CASCADE
И теперь можно назначить новые права пользователю user4
GRANT EXECUTE
ON COUNT_EX
TO user4
Системный администратор может разрешить некоторому пользователю создавать и изменять таблицы в некоторой БД. Тогда он может записать оператор предоставления прав следующим образом:
GRANT CREATE TABLE ALTER TABLE DROP TABLE
ON DB_LIB
TO user1
В этом случае пользователь user1 может создавать, изменять или удалять таблицы в БД DB_LIB, однако он не может разрешить создавать или изменять таблицы в этой БД другим пользователям, потому что ему дано разрешение без права делегирования своих возможностей.
В некоторых СУБД пользователь может получить права создавать БД. Например, в MS SQL Server системный администратор может предоставить пользователю main_user право на создание своей БД на данном сервере. Это может быть сделано следующей командой:
GRANT CREATE DATABASE
ON SERVER_0
TO main_user
По принципу иерархии пользователь main_user, создав свою БД, теперь может предоставить права на создание или изменение любых объектов в этой БД другим пользователям.
В СУБД, которые поддерживают однобазовую архитектуру, такие разрешения недопустимы. Например, в СУБД Oracle на сервере создается только одна БД, но пользователи могут работать на уровне подсхемы (части таблиц БД и связанных с ними объектов). Поэтому там вводится понятие системных привилегий. Их очень много, 80 различных привилегий.
Для того чтобы разрешить пользователю создавать объекты внутри этой БД, используется понятие системной привилегии, которая может быть назначена одному или нескольким пользователям. Они выдаются только на действия и конкретный тип объекта. Поэтому если системный администратор предоставил пользователю право создания таблиц (CREATE TABLE), то для того чтобы он мог создать триггер для таблицы, ему необходимо предоставить еще одну системную привилегию CREATE TRIGGER. Система защиты в Oracle считается одной из самых мощных, но это имеет и обратную сторону -- она весьма сложная. Поэтому задача администрирования в Oracle требует хорошего знания как семантики принципов поддержки прав доступа, так и физической реализации этих возможностей.
Реализация системы защиты в MS SQL Server
Система управления базами данных Microsoft SQL Server 2000 имеет разнообразные средства защиты данных.
Система безопасности базируется на пользователях и учетных записях. Каждый пользователь проходит два этапа проверки системой безопасности. На первом этапе пользователь идентифицируется с помощью регистрационного, или логическом имени и пароля, которые хранятся на сервере SQL Server или в домене Windows NT/2000 в виде учетной записи. Таким образом, пользователь проходит аутентификацию. Если данные введены правильно, пользователь подключается к SQL Server. Подключение к SQL Server, или регистрация, не дает автоматического доступа к базам данных. Для каждой базы данных сервера учетная запись должна отображаться в пользователя базы дачных. На втором этапе на основе прав, выданных человеку (или приложению) как пользователю базы данных, его учетная запись получает доступ к соответствующей базе данных. В разных базах данных одной и той же учетной записи могут соответствовать одинаковые или разные имена пользователя базы данных с разными правами доступа.
Для доступа к базам данных приложений им также понадобятся права. Чаще всего, приложениям выдаются те же права, что предоставлены пользователям, запускающим эти приложения. Однако для работы некоторых приложений необходимо иметь фиксированный набор прав доступа, не зависящих от прав доступа пользователя. SQL Server 2000 позволяет сделать это путем назначения специальных ролей приложения.
На уровне сервера система безопасности оперирует следующими понятиями:
- аутентификация;
- учетная запись;
- встроенные роли сервера.
На уровне базы данных используются следующие понятия:
- пользователь базы данных;
- фиксированная роль базы данных;
- пользовательская роль базы данных;
- роль приложения.
Компоненты структуры безопасности. Фундаментом системы безопасности SQL Server 2000 являются учетные записи, пользователи, роли и группы.
Пользователь, подключающийся к SQL Server, должен идентифицировать себя, используя учетную запись. После того как клиент успешно прошел аутентификацию, он получает доступ к SQL Server. Для получения доступа к любой базе данных учетная запись пользователя отображается в пользователя данной базы данных. Пользователю базы данных предоставляется доступ ко всем объектам базы данных: таблицам, представлениям, хранимым процедурам и т. д.
Пользователи баз данных, в свою очередь, могут объединяться в группы и роли для упрощения управления системой безопасности.
К средствам Transact-SQL, используемым для управления системой безопасности, относится хранимая процедура sp_addlogin. С помощью этой процедуры можно создать новую учетную запись SQL Server.
Хранимая процедура sp_grantlogin позволяет разрешить доступ к SQL Server для пользователя или группы Windows NT.
Пользователи. После того как пользователь прошел аутентификацию и получил идентификатор учетной записи, он считается зарегистрированным и ему предоставляется доступ к серверу. Для каждой базы данных, к объектам которой пользователю необходимо получить доступ, учетная запись пользователя ассоциируется с пользователем конкретной базы данных. Пользователи выступают в качестве специальных объектов SQL Server, при помощи которых определяются все разрешения доступа и владения объектами в базе данных.
При создании базы данных определяются два стандартных пользователя: dbo и guest. Если учетная запись пользователя явно не отображается в пользователя базы данных, пользователю предоставляется неявный доступ с использованием гостевого имени guest. Обычно пользователю guest предоставляется минимальный доступ в режиме «только чтение».
Для обеспечения максимальной безопасности можно удалить пользователя guest из всех баз данных, кроме системных баз данных master и tempdb.
Владелец базы данных -- специальный пользователь, обладающий максимальными правами в базе данных.
Пользователь, который создает объект в базе данных, например, таблицу, хранимую процедуру, представление и т. д., становится владельцем объекта. Владелец объекта базы данных имеет все права доступа к созданному объекту. Чтобы пользователь мог создать объект, владелец базы данных должен предоставить пользователю соответствующие права. Полное имя создаваемого объекта включает в себя имя создавшего его пользователя.
Владелец объекта не имеет никакого специального пароля или особых прав доступа. Он неявно имеет полный доступ к объекту, но должен явно предоставить доступ другим пользователям.
SQL Server позволяет передавать права владения от одного пользователя другому. Чтобы удалить владельца объекта из базы данных, сначала необходимо удалить все объекты, которые он создал, или передать права на их владение другому пользователю.
Роли сервера. Роли -- это мощный инструмент, добавленный в SQL Server 7.0 и заменивший группы, которые использовались в более ранних версиях. Роль позволяет объединять пользователей, выполняющих одинаковые функции, для упрощения администрирования системы безопасности SQL Server. Роли бывают встроенными и пользовательскими. Первые создаются автоматически при установке сервера (и их состав не может изменяться), тогда, как вторые создаются пользователями.
В SQL Server реализованы два вида стандартных ролей: на уровне сервера и на уровне баз данных. При установке SQL Server 2000 создается 9 фиксированных ролей сервера и 9 фиксированных ролей базы данных. Эти роли нельзя удалить. Кроме того, нельзя модифицировать права их доступа.
Роли баз данных. Роли базы данных позволяют объединять пользователей в одну административную единицу и работать с ней как с обычным пользователем. Можно назначить права доступа к объектам базы данных для конкретной роли, наделяя тем самым всех членов этой роли соответствующими правами. Вместо того чтобы предоставлять доступ каждому конкретному пользователю, а впоследствии постоянно следить за изменениями, можно просто включить пользователя в нужную роль. Если сотрудник переходит в другой отдел, нужно просто удалить его из одной роли и добавить в другую. Создав необходимое количество ролей, которые по возможности охватывали бы все многообразие действий с базой данных, достаточно, при изменении функций членов одной из ролей, изменить права доступа для этой роли, а не устанавливать новые права для каждого пользователя.
В роль базы данных можно включать:
- пользователей SQL Server;
- роли SQL Server;
- пользователей Windows NT;
- группы Windows NT, которым предварительно предоставлен доступ к нужной базе данных.
При создании базы данных для нее определяются стандартные роли базы данных, которые, так же как и стандартные роли сервера, не могут быть изменены или удалены.
Кроме указанных выше ролей существует еще одна -- public. Эта роль имеет специальное назначение, поскольку ее членами являются все пользователи, имеющие доступ к базе данных. Нельзя явно установить членов этой роли, потому что все пользователи и так автоматически являются ее членами. Рекомендуется использовать эту роль для предоставления минимального доступа пользователям, для которых права доступа к объектам не определены явно. Если в базе данных разрешен пользователь guest, то установленный для роли public доступ будут иметь все пользователи, получившие доступ к SQL Server. Роль public имеется во всех базах данных, включая системные базы данных master, tempdb, msdb, model, и не может быть удалена.
Подобные документы
Базы данных с двумерными файлами и реляционные системы управления базами данных (СУБД). Создание базы данных и обработка запросов к ним с помощью СУБД. Основные типы баз данных. Базовые понятия реляционных баз данных. Фундаментальные свойства отношений.
реферат [57,1 K], добавлен 20.12.2010Базы данных (БД) и системы управления базами данных (СУБД) как основы современной информационной технологии, их роль в хранении и обработке информации. Этапы реализации БД, средств ее защиты и поддержки целостности. Протоколы фиксации и отката изменений.
презентация [364,2 K], добавлен 22.10.2013Реализация приложения "Книжный магазин" средствами систем управления базами данных. Проектирование структуры базы данных, определение сущности и атрибутов. Логическое проектирование базы данных и реализация базы данных в СУБД Microsoft Office Access.
курсовая работа [7,8 M], добавлен 13.02.2023Основные этапы проектирования базы данных. Access как система управления базами данных (СУБД), ее предназначение, отличительные возможности. Работа с таблицами, их создание и редактирование. Порядок создания запросов. Способы защиты баз данных.
лабораторная работа [3,1 M], добавлен 18.08.2009Системы управления базами данных: сущность и характеристика. Типы данных и свойства полей СУБД Access. Объекты базы данных: таблицы, схемы данных, формы, запросы, отчеты. Разработка и проектирование базы данных "Продажи книг" в среде Microsoft Access.
курсовая работа [1,8 M], добавлен 04.02.2013Базы данных и системы управления базами данных. Структура простейшей базы данных, свойства полей. Понятие языка SQL. Проектирование баз данных, режимы работы, объекты. СУБД Microsoft Access. Создание базы данных "Электротовары" средствами Visual FoxPro.
курсовая работа [5,7 M], добавлен 29.04.2014Изучение основных понятий баз данных: структура простейшей базы данных, компоненты базы данных Microsoft Access. Проектирование базы данных "Туристическое агентство" в СУБД Access 2010, в которой хранятся данные о клиентах, которые хотят поехать отдыхать.
курсовая работа [3,3 M], добавлен 20.09.2013Основные принципы проектирования реляционных баз данных и их практическая реализация в MS Access. Концептуальная и логическая модели реляционной базы данных, ее физическое проектирование. Автоматизация процесса взаимодействия с клиентами и поставщиками.
курсовая работа [2,8 M], добавлен 10.03.2015Операции в системе управления базами данных (СУБД). MS Access как функционально полная реляционная СУБД. Разработка реляционных моделей баз данных экономического направления. Применение прикладных программ для решения экономико-управленческих задач.
курсовая работа [2,1 M], добавлен 14.01.2015Понятие и сущность базы данных, их классификация и характеристика. Системы управления базами данных. СУБД структуры "сервер-клиент", его суть. Microsoft Access - функционально полная реляционная СУБД. Предназначение СУБД Access, и описание ее работы.
реферат [44,3 K], добавлен 27.02.2009
