государственное автономное профессиональное образовательное учреждение
Чувашской Республики «Чебоксарский электромеханический колледж»
Министерства образования и молодежной политики Чувашской Республики
ПМ.02Разработка и администрирование баз данных
ОТЧЕТ
по учебной практике
УП.ПР2-13.03.УП.02.01ОТ
Выполнил студент 4 курса, группы Пр2-13
(подпись) (чч.мм.гггг)
Преподаватель
(Фамилия И. О.)
Зачтено
(чч.мм.гггг)
Подпись
(подпись) (расшифровка подписи)
2015
|
Изм. |
|
Лист |
|
№ докум. |
|
Подпись |
|
Дата |
|
Лист |
|
2 |
|
Разраб. |
|
Евграфов Д.В. |
|
Провер. |
|
Федотова Н.И. |
|
Реценз. |
|
Н. Контр. |
|
Утверд. |
|
Лит. |
|
Листов |
|
|
|
ЧЭМК |
СОДЕРЖАНИЕ:
1 Практическая работа №1. Название.......................................................... №стр
2 Практическая работа №2. Название ...........................................................№стр
И Т.Д.
|
УП.ПР2-13.03.УП.02.01ОТ |
|
1 |
|
Отчет по учебной практике |
|
Изм. |
|
Лист |
|
№ доку . |
|
Подпись |
|
Дата |
|
Лист |
|
4 |
|
УП.ПР2-13.03.УП.02.01ОТ
|
Практическая работа № 1
Тема: Работа по определению предметных областей
Цель: Научиться анализу предметных областей информационных систем
Задание: Исследовать предметную область БД «Гостиница»
Использованные технические средства и ПО:MicrosoftAccess
Общая информация
Основным назначением информационных систем является оперативное обеспечение пользователя информацией о внешнем мире путем реализации вопросно-ответного отношения. Вопросно-ответные отношения, получая интерпретацию во внешнем мире (мире вне информационной системы), позволяют выделить для информационной системы определенный его фрагмент - предметную область, - который будет воплощен в автоматизированной информационной системе. Информация о внешнем мире представляется в информационной системе (ИС) в форме данных. Это ограничивает возможности смысловой интерпретации информации и конкретизирует семантику ее представления в ИС. Совокупность этих выделенных для ИС данных, связей между ними и операций над ними образуетинформационную и функциональную модели предметной области, описывающие ее состояние с определенной точностью.
Важно понимать, что информационная и функциональная модели предметной области создаются на этапе анализа требований к базе данных и не содержат предположений о технологии реализации базы данных. Они строятся независимо от выбираемой модели данных (сетевой, иерархической, реляционной, объектно-ориентированной, многомерной и т.д.), поддерживаемой СУБД, модели вычислений, программно-аппаратной платформы для базы данных. Информационная и функциональная модели предметной области являются входными данными для процесса проектирования базы данных. Поэтому проектировщик должен уметь правильно интерпретировать их в ходе решения своих проектных задач.
|
Изм. |
|
Лист |
|
№ доку . |
|
Подпись |
|
Дата |
|
Лист |
|
5 |
|
УП.ПР2-13.03.УП.02.01ОТ
|
Понятие предметной области базы данных является одним из базовых понятий информатики и не имеет точного определения. Его использование в контексте ИС предполагает существование устойчивой во времени соотнесенности между именами, понятиями и определенными реалиями внешнего мира, не зависящей от самой ИС и ее круга пользователей. Таким образом, введение в рассмотрение понятия предметной области базы данных ограничивает и делает обозримым пространство информационного поиска в ИС и позволяет выполнять запросы за конечное время.
Совокупность реалий (объектов) внешнего мира - объектов, о которых можно задавать вопросы, - образует объектное ядро предметной области, которое имеет онтологический статус. Нельзя получить в ИС ответ на вопрос о том, что ей неизвестно. Термин объектявляется первичным, неопределяемым понятием. Синонимами термина "объект" являются "реалия, сущность, вещь". Однако термин сущность понимается нами несколько уже, как компонент модели предметной области, т.е. как уже выделенный на концептуальном уровне объект для базы данных. Таким образом, выделяемые в предметной области объекты превращаются аналитиками (а не проектировщиками базы данных) в сущности. Сущность предметной области является результатом абстрагирования реального объекта путем выделения и фиксации набора его свойств. Сущность является результатом абстрагирования реального объекта, т.е. в нашем контексте имеет гносеологический статус. Хотя далее в контексте сущность нередко отождествляется с объектом.
Определение. Предметная область - это целенаправленная первичная трансформация картины внешнего мира в некоторую умозрительную картину, определенная часть которой фиксируется в ИС в качестве алгоритмической моделифрагмента действительности.
Ход работы:
|
Изм. |
|
Лист |
|
№ доку . |
|
Подпись |
|
Дата |
|
Лист |
|
6 |
|
УП.ПР2-13.03.УП.02.01ОТ
|
Рисунок 1 - Таблица «Забронированные номера»
Рисунок 2 - Таблица «Клиент»
Рисунок 3 - Таблица «Номера»
Рисунок 4 - Таблица «Оплата»
Рисунок 5 - Таблица « Комнаты»
|
Изм. |
|
Лист |
|
№ доку . |
|
Подпись |
|
Дата |
|
Лист |
|
7 |
|
УП.ПР2-13.03.УП.02.01ОТ
|
Рисунок 6 - Схема данных БД «Гостиница
|
Изм. |
|
Лист |
|
№ доку . |
|
Подпись |
|
Дата |
|
Лист |
|
7 |
|
УП.ПР2-13.03.УП.02.01ОТ
|
Практическая работа № 2
Тема: Основные методы и средства защиты данных в БД, работа по исполнению различных моделей данных
Цель: Научиться исполнять различные модели данных, определять методы их защиты
Задание: Составить наиболее приемлемую и оптимальную по защите данных модель данных дляБД «Гостиница»
Использованные технические средства и ПО:MicrosoftAccess
Общая информация
Реляционная модель данных использует организацию данных в виде двумерных таблиц. Каждая такая таблица, называемая реляционной таблицей или отношением, представляет собой двумерный массив и обладает следующими свойствами:
· все столбцы в таблице однородные, т.е. все элементы в одном столбце имеют одинаковый тип и максимально допустимый размер;
· каждый столбец имеет уникальное имя;
· одинаковые строки в таблице отсутствуют;
· порядок следования строк и столбцов в таблице не имеет значения. Основными структурными элементами реляционной таблицы являются поле и запись. Поле (столбец реляционной таблицы) – элементарная единица логической организации данных, которая соответствует конкретному атрибуту информационного объекта. Запись (строка реляционной таблицы) – совокупность логически связанных полей, соответствующая конкретному экземпляру информационного объекта.
Этапы проектирования реляционной базы данных В процессе разработки базы данных можно выделить несколько этапов. Анализ предметной области. На этом этапе формируется задание по созданию базы данных. В нем подробно описывается состав базы данных, назначение и цели ее создания, а также перечисляется, какие виды работ предполагается осуществлять в этой базе
данных (отбор, изменение данных, печать или вывод отчета и т. д.). Разработка схемы данных БД. На этом этапе рассматривается, из каких информационных объектов должна состоять база данных, какими атрибутами описывается каждый объект. Затем определяется структура реляционных таблиц с указанием свойств полей и связей между таблицами. Синтез компьютерной модели объекта, предполагающий выполнение следующих типовых операций:
1) создание файла базы данных;
2) создание базовых таблиц;
3) создание экранных форм для ввода, редактирования и просмотра данных в таблицах;
4) заполнение таблиц данными;
5) работа с созданной базой данных:
< >сортировка, фильтрация и поиск записей в таблицах;отбор данных из таблиц в соответствии с заданными критериями отбора;выполнение обработки данных (удаление, добавление, изменение данных, выполнение вычислений); подготовка отчетов.В стандарте SQL определены два оператора: GRANT и REVOKE соответственно предоставления и отмены привилегий.
Оператор предоставления привилегий имеет следующий формат:
GRANT {<списокдействий> | ALL PRIVILEGES }
ON<Оплата>
TO{PUBLIC }
[WITH GRANT OPTION ]
Здесь список действий определяет набор действий из общедопустимого перечня действий над объектом данного типа.
Параметр ALL PRIVILEGES указывает, что разрешены все действия из допустимых для объектов данного типа.
<имя_объекта> — задает имя конкретного объекта: таблицы, представления, хранимой процедуры, триггера.
<имя_пользователя> или PUBLIC определяет, кому предоставляются данные привилегии.
Параметр WITH GRANT OPTION является необязательным и определяет режим, при котором передаются не только права на указанные действия, но и право передавать эти права другим пользователям. Передавать права в этом случае пользователь может только в рамках разрешенных ему действий.
Рассмотрим пример, пусть у нас существуют три пользователя с абсолютно уникальными именами user1, user2 и user3. Все они являются пользователями одной БД.
User1 создал объект Tab1, он является владельцем этого объекта и может передать права на работу с эти объектом другим пользователям. Допустим, что пользователь user2 является оператором, который должен вводить данные в Tab1 (например, таблицу новых заказов), а пользователь user 3 является большим начальником (например, менеджером отдела), который должен регулярно просматривать введенные данные.
Для объекта типа таблица полным допустимым перечнем действий является набор из четырех операций: 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.
При назначении прав доступа на операцию модификации можно уточнить, значение каких столбцов может изменять пользователь. Допустим, что менеджер отдела имеет право изменять цену на предоставляемые услуги. Предположим, что цена задается в столбцеCOST таблицы Tab1. Тогда операция назначения привилегий пользователю user3 может измениться и выглядеть следующим образом:
GRANT SELECT, UPDATE (COST)
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
FROM user4 CASCADE
будут отменены привилегии и пользователя user5, которому пользователь user4 успел присвоить привилегии.
Параметр RESTRICT ограничивает отмену привилегий только пользователю, непосредственно упомянутому в операторе REVOKE. Но при наличии делегированных привилегий этот оператор не будет выполнен. Так, например, операция:
REVOKE ALL PRIVILEGES
ON Tab1 TO user4 RESTRICT
не будет выполнена, потому что пользователь user4 передал часть cвоих полномочий пользователю 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
|
Изм. |
|
Лист |
|
№ доку . |
|
Подпись |
|
Дата |
|
Лист |
|
8 |
|
УП.ПР2-13.03.УП.02.01ОТ
|
Ход работы:
Рисунок 7 - Реляционная модель данных
Практическая работа № 3
Тема: Основы разработки БД. Корректная работа по нормализации отношений
Цель: Научиться нормализовать отношения в соответствии с поставленной задачей
Задание: Выполнить нормализацию отношений для БД «Гостиница»
Использованные технические средства и ПО:MicrosoftAccess
Общая информация
Нормализация — это процесс организации данных в базе данных, включающий создание таблиц и установление отношений между ними в соответствии с правилами, которые обеспечивают защиту данных и делают базу данных более гибкой, устраняя избыточность и несогласованные зависимости.
Избыточность данных приводит к непродуктивному расходованию свободного места на диске и затрудняет обслуживание баз данных. Например, если данные, хранящиеся в нескольких местах, потребуется изменить, в них придется внести одни и те же изменения во всех этих местах. Изменение адреса клиента гораздо легче реализовать, если в базе данных эти сведения хранятся только в таблице Customers и нигде больше.
Что такое «несогласованные зависимости»? Пользователь, которому нужно узнать, например, адрес определенного клиента, вполне обоснованно будет искать его в таблице Customers (клиенты), но искать в ней сведения о зарплате сотрудника, который работает с этим клиентом, не имеет смысла. Зарплата сотрудника связана с сотрудником (зависит от него), поэтому эти сведения следует хранить в таблице Employees (сотрудники). Несогласованные зависимости могут затруднять доступ к данным, так как путь к данным при этом может отсутствовать или быть неправильным.
Существует несколько правил нормализации баз данных. Каждое правило называется «нормальной формой». Если выполняется первое правило, говорят, что база данных представлена в «первой нормальной форме». Если выполняются три первых правила, считается, что база данных представлена в «третьей нормальной форме». Есть и другие уровни нормализации, однако для большинства приложений достаточно нормализовать базы данных до третьей нормальной формы.
Первая нормальная форма
< >Устраните повторяющиеся группы в отдельных таблицах.Создайте отдельную таблицу для каждого набора связанных данных.Идентифицируйте каждый набор связанных данных с помощью первичного ключа.Создайте отдельные таблицы для наборов значений, относящихся к нескольким записям.Свяжите эти таблицы с помощью внешнего ключа.Устраните поля, не зависящие от ключа.
|
Изм. |
|
Лист |
|
№ докум. |
|
Подпись |
|
Дата |
|
Лист |
|
PAGE * LOWER 1 |
|
УП.ПР2-13.03.УП.02.01ОТ
|
Рисунок 8 - Таблица до нормализации
Практическая работа № 4
Тема: Работа по созданию объектов БД(таблиц, запросов)
Цель: Научиться создавать объекты в конкретной СУБД(таблицы, запросы)
Задание:
Использованные технические средства и ПО:
ПЕРЕЧИСЛИТЬ!
Общая информация
Объекты базы данных
Таблицы. Это основные объекты любой базы данных. Именно в них хранятся, во-первых, все данные, имеющиеся в базе, а, во-вторых, структура самой базы (поля, их типы и свойства).
Запросы. Это объекты предназначены для извлечения данных из таблиц и предоставления их пользователю в удобном виде. Особенность запросов состоит в том, что берут информацию из базовых таблиц и создают на их основе временную результирующую таблицу, которая не имеет аналога на жестком диске, это только образ отобранных полей и записей.
Формы. Это средства для ввода и просмотра данных. С помощью форм можно закрыть некоторые поля для несанкционированного ввода, можно разместить специальные элементы управления (счетчики, раскрывающиеся списки, переключатели, флажки и пр.) для автоматизации ввода. Можно представить форму с помощью графических средств, в виде бланка, если ввод производится со специальных бланков.
С помощью формы можно не только вводить данные, но и отображать, применяя специальные средства.
Отчеты. Предназначены для вывода данных на печатающее устройство. В них приняты специальные меры для группирования выводимых данных и для вывода специальных элементов оформления, характерных для печатных документ.
Макросы и модули. Эти объекты предназначены как для автоматизации повторяющихся операций при работе с СУБД, так и для создания новых функций путем программирования. Макросы состоят из последовательности внутренних команд СУБД Access и являются одним из средств автоматизации работы с базой. Модули создаются средствами внешнего языка программирования Visual Basic for Applications
Ход работы:
Рисунок 2 - Таблица «Клиент»
Рисунок 2 - Таблица «Клиент»
Рисунок 3 - Таблица «Номера»
Рисунок 4 - Таблица «Оплата»
Рисунок 5 - Таблица « Комнаты»
|
Изм. |
|
Лист |
|
№ докум. |
|
Подпись |
|
Дата |
|
Лист |
|
PAGE * LOWER 1 |
|
УП.ПР2-13.03.УП.02.01ОТ
|
Практическая работа № 5
Тема: Создание объектов БД(формы, отчеты)
Цель: Научиться
Задание: Выполнить нормализацию отношений для БД «Больница»
Использованные технические средства и ПО:
ПЕРЕЧИСЛИТЬ!
Общая информация
Ход работы:
|
Изм. |
|
Лист |
|
№ докум. |
|
Подпись |
|
Дата |
|
Лист |
|
PAGE * LOWER 1
|
|
УП.ПР2-13.03.УП.02.01ОТ
|
Практическая работа № 6
Тема: Установка атрибутов и ключей
Цель: Научиться корректной установке атрибутов и ключей в БД
Задание:
Использованные технические средства и ПО:
ПЕРЕЧИСЛИТЬ!
Общая информация
Ход работы:
|
Изм. |
|
Лист |
|
№ докум. |
|
Подпись |
|
Дата |
|
Лист |
|
PAGE * LOWER 1 |
|
УП.ПР2-13.03.УП.02.01ОТ
|
|
Изм. |
|
Лист |
|
№ докум. |
|
Подпись |
|
Дата |
|
Лист |
|
PAGE * LOWER 1 |
|
УП.ПР2-13.03.УП.02.01ОТ
|