Учебник Информатика. Базовый курс. Симонович С.В.. С. В. Симоновичаинформатикабазовый курс2е издание
 Скачать 17.96 Mb.
|
|
Типы данных С основными типами данных мы уже знакомы. Так, например, при изучении элек- тронных таблиц Microsoft Excel мы видели, что они работают с тремя типами дан- ных: текстами, числами и формулами. Таблицы баз данных, как правило, допускают работу с гораздо большим количеством разных типов данных. Так, например, базы данных Microsoft Access работают со следующими типами данных (рис. 13.2). Поле Текстовые поле Логическое поле Поле Рис. Таблица с полями некоторых типов Текстовый — тип данных, используемый для хранения обычного неформатиро- ванного текста ограниченного размера (до 255 символов). Поле Мемо — специальный тип данных для хранения больших объемов текста (до 65 535 символов). Физически текст не хранится в поле. Он хранится в дру- гом месте базы данных, а в поле хранится указатель на него, но для пользователя такое разделение заметно не всегда. Числовой — тип данных для хранения действительных чисел. Дата/время — тип данных для хранения календарных дат и текущего времени. Денежный — тип данных для хранения денежных сумм. Теоретически, для их записи можно было бы пользоваться и полями числового типа, но для денежных сумм есть некоторые особенности (например, связанные с правилами округле- ния), которые делают более удобным использование специального типа дан- ных, а не настройку числового типа. Счетчик — специальный тип данных для уникальных (не повторяющихся в поле) натуральных чисел с автоматическим наращиванием. Естественное исполь- зование — для порядковой нумерации записей. 3 4 4 Глава Работа с базами данных • Логический — тип для хранения логических данных (могут принимать только два значения, например Да или Нет). • Поле объекта OLE — специальный тип данных, предназначенный для хранения объектов OLE, например мультимедийных. Реально, конечно, такие объекты в таблице не хранятся. Как и в случае полей MEMO, они хранятся в другом месте внутренней структуры файла базы данных, а в таблице хранятся только указа- тели на них (иначе работа с таблицами была бы чрезвычайно замедленной). • Гиперссылка — специальное поле для хранения адресов URL для Web-объектов Интернета. При щелчке на ссылке автоматически происходит запуск браузера и воспроизведение объекта в его окне. • Мастер подстановок — это не специальный тип данных. Это объект, настройкой которого можно автоматизировать ввод данных в поле так, чтобы не вводить их вручную, а выбирать из раскрывающегося списка. Безопасность баз данных Базы данных — это тоже файлы, но работа с ними отличается от работы с файлами других типов, создаваемых прочими приложениями. Выше мы видели, что всю работу по обслуживанию файловой структуры берет себя операционная система. Для баз данных предъявляются особые требования с точки зрения безопасности, поэтому в них реализован другой подход к сохранению данных. При работе с обычными приложениями для сохранения данных мы выдаем соответ- ствующую команду, задаем имя файла и доверяемся операционной системе. Если мы закроем файл, не сохранив его, то вся работа по созданию или редактированию файла пропадет безвозвратно. Базы данных — это особые структуры. Информация, которая в них содержится, очень часто имеет общественную ценность. Нередко с одной и той же базой (напри- мер, с базой регистрации автомобилей в ГИБДД) работают тысячи людей по всей стране. От информации, которая содержится в некоторых базах, может зависеть благополучие множества людей. Поэтому целостность содержимого базы не может и не должна зависеть ни от конкретных действий некоего пользователя, забывшего сохранить файл перед выключением компьютера, ни от перебоев в электросети. Проблема безопасности баз данных решается тем, что в для сохранения информации используется двойной подход. В части операций, как обычно, участ- вует система компьютера, но некоторые операции сохранения про- исходят в обход операционной системы. Операции изменения структуры базы данных, создания новых таблиц или иных объектов происходят при сохранении файла базы данных. Об этих операциях СУБД предупреждает пользователя. Это, так сказать, глобальные операции. Их никогда не проводят с базой данных, находящейся в коммерческой эксплуатации, — только с ее копией. В этом случае любые сбои в работе вычислительных систем не страшны. С другой стороны, операции по изменению содержания данных, не затрагиваю- щие структуру базы, максимально автоматизированы и выполняются без предуп- Формирование данных 3 4 5 реждения. Если, работая с таблицей данных, мы что-то в ней меняем в составе дан- ных, то изменения сохраняются немедленно и автоматически. Обычно, решив отказаться от изменений в документе, его просто закрывают без сохранения и вновь открывают предыдущую копию. Этот прием работает почти во всех приложениях, но только не в СУБД. Все изменения, вносимые в таблицы базы, сохраняются на диске без нашего ведома, поэтому попытка закрыть базу «без сохранения» ничего не даст, так как все уже сохранено. Таким образом, редактируя таблицы баз данных, создавая новые записи и удаляя старые, мы как бы работаем с жестким диском напрямую, минуя операционную систему. По указанным выше причинам нельзя заниматься учебными экспериментами на базах данных, находящихся в эксплуатации. Для этого следует создавать специальные учебные базы или выполнять копии структуры реальных баз (без фактического наполнения данными). Формирование баз данных Режимы работы с базами данных Обычно с базами данных работают две категории исполнителей. Первая категория — Их задача состоит в разработке структуры таблиц базы данных и согласовании ее с заказчиком. Кроме таблиц проектировщики разрабатывают и другие объекты базы данных, предназначенные, с одной стороны, для автоматиза- ции работы с базой, а с другой стороны — для ограничения функциональных воз- можностей работы с базой (если это необходимо из соображений безопасности). Проектировщики не наполняют базу конкретными данными (заказчик может счи- тать их конфиденциальными и не предоставлять посторонним лицам). Исключение составляет экспериментальное наполнение модельными данными на этапе отладки объектов базы. Вторая категория исполнителей, работающих с базами данных, — пользователи. Они получают исходную базу данных от проектировщиков и занимаются ее напол- нением и обслуживанием. В общем случае пользователи не имеют средств доступа к управлению структурой базы — только к данным, да и то не ко всем, а к тем, работа с которыми предусмотрена на конкретном рабочем месте. Соответственно, система управления базами данных имеет два режима работы: проектировочный и пользовательский. Первый режим предназначен для создания или изменения структуры базы и создания ее объектов. Во втором режиме проис- ходит использование ранее подготовленных объектов для наполнения базы или получения данных из нее. Объекты базы данных уже упомянули о том, что кроме таблиц база данных может содержать и другие типы объектов. Привести полную классификацию возможных объектов баз данных затруднительно, поскольку каждая система управления базами данных может реализовать свои типы объектов. Однако основные типы объектов мы можем 3 4 6 Глава Работа данных рассмотреть на примере Microsoft Access. В версии Microsoft Access 2002 эта позволяет создавать и использовать объекты семи различных типов. Таблицы. Как мы уже говорили, это основные объекты любой базы данных. Во-пер- вых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хра- нят и структуру базы (поля, их типы и свойства). Запросы. Эти объекты служат для извлечения данных из таблиц и предоставления их пользователю в удобном виде. С помощью запросов выполняют такие операции, как отбор данных, их сортировку и фильтрацию. С помощью запросов можно выпол- нять преобразование данных по заданному алгоритму, создавать новые таблицы, выполнять автоматическое наполнение таблиц данными, импортированными из других источников, выполнять простейшие вычисления в таблицах и многое другое. Начинающие пользователи не сразу понимают роль запросов, поскольку все те же операции можно делать и с таблицами. Да, действительно, это так, но есть сообра- жения удобства (в первую очередь быстродействия) и соображения безопасности. Из соображений безопасности, чем меньше доступа к базовым таблицам имеют конечные пользователи, тем лучше. Во-первых, снижается риск того, что неуме- лыми действиями они повредят данные в таблицах. Во-вторых, предоставив раз- ным пользователям разные запросы, можно эффективно разграничить их доступ к данным в строгом соответствии с кругом персональных обязанностей. В банках, например, одни сотрудники имеют доступ к таблицам данных о клиентах, другие — к их расчетным счетам, третьи — к таблицам активов банка. Если и есть специаль- ные службы, имеющие доступ ко всем информационным ресурсам банка (с целью контроля и анализа), то они лишены средств для внесения изменений — все сделано так, чтобы один человек не мог совершить фиктивную операцию, независимо от того, какую должность он занимает. В базе данных, имеющей правильно организо- ванную структуру, для совершения противоправных действий необходим сговор нескольких участников, а такие действия пресекаются не программными, а тради- ционными средствами обеспечения безопасности. Особенность запросов состоит в том, что они черпают данные из базовых таблиц и создают на их основе временную результирующую таблицу. Если хотят подчерк- нуть факт «временности» этой таблицы, то ее еще называют моментальным сним- ком. Когда мы работаем с основными таблицами базы, мы физически имеем дело с жестким диском, то есть с очень медленным устройством (напомним, что это свя- зано с особенностью сохранения данных, описанной выше). Когда же на основании запроса мы получаем результирующую таблицу, то имеем дело с электронной таб- лицей, не имеющей аналога на жестком диске, — это только образ отобранных полей и записей. Разумеется, работа с «образом» происходит гораздо быстрее и эффек- тивнее — это еще одно основание для того, чтобы широко использовать запросы. Когда в главе 1 мы обсуждали основные структуры данных, то отметили, что недо- статком упорядоченных табличных структур является сложность их обновления, поскольку при внесении новых записей нарушается упорядоченность — прихо- дится переделывать всю таблицу. В системах управления базами данных и эта про- блема решается благодаря запросам. Формирование баз данных 347 Основной принцип состоит в том, что от базовых таблиц никакой упорядоченности не требуется. Все записи в основные таблицы вносятся только в естественном порядке по мере их поступления, то есть в неупорядоченном виде. Если же пользо- вателю надо видеть данные, отсортированные или отфильтрованные по тому или иному принципу, он просто использует соответствующий запрос (рис. 13.3). Если нужного запроса нет, он обращается к проектировщику и просит его такой запрос сделать и предоставить. Б а з о в а я Результирующая т а б л и ц а Результирующая т а б л и ц а Проведена сортировка по цене Проведена сортировка по имени Рис. 13.3. Два запроса, сформированные на основе одной таблицы Формы. Если запросы — это специальные средства для отбора и анализа данных, то фор- мы — это средства для ввода данных. Смысл их тот же — предоставить пользователю сред- ства для заполнения только тех полей, кото- рые ему заполнять положено. Одновременно с этим в форме можно разместить специаль- ные элементы управления (счетчики, раскры- вающиеся списки, переключатели, флажки и прочие) для автоматизации ввода. Преимущества форм раскрываются особенно наглядно, когда происходит ввод данных с заполненных бланков. В этом случае форму делают графическими средст- вами так, чтобы она повторяла оформление бланка, — это заметно упрощает работу наборщика, снижает его утомление и предотвращает появление печатных ошибок. На сопроводительном рисунке приведен пример простейшей формы для ввода данных. 348 Глава Работа с базами данных С помощью форм данные можно не только вводить, но и отображать. Запросы тоже отображают данные, но делают это в виде результирующей таблицы, не имеющей почти никаких средств оформления. При выводе данных с помощью форм можно применять специальные средства оформления (рис. 13.4). Pentium 4 "Кристина" И « 13.4. Форма для оформленного вывода данных Отчеты. По своим свойствам и структуре отчеты во многом похожи на формы, но предназначены только для вывода данных, для не на экран, а на печатающее устройство (принтер). В связи с этим отличаются тем, что в них специальные меры для группирования выводимых данных и для вывода специальных элементов оформления, характерных для печатных докумен- тов (верхний и нижний колонтитулы, номера страниц, служебная информация о времени создания отчета и т. п.) (рис. 13.5). Комплектующие Цена Микропроцессор Pentium 4 Pentium 4 4 Pentium 4 4 Pentium 4 1.8 2,4A 2,8C 135 OOO "Самшит" 0 0 0 178 "Планета" 182 "Паритет" 319 АОЗТ "Кристина" АОЗТ "Кристина" Страница; jj Г 13.5. Пример простейшего отчета Страницы. Это специальные объекты баз данных, реализованные в последних вер- сиях СУБД Microsoft Access. Правда, более корректно их называть страницами доступа к данным. Физически это особый объект, выполненный в HTML, раз- мещаемый на и передаваемый клиенту вместе с ней. Сам по себе этот объект не является базой данных, но содержит компоненты, через которые осуществляется связь переданной Web- страницы с базой данных, остающейся на сервере. Пользуясь этими компонентами, посетитель может просматри- 1 3.2. Формирование баз данных 349 вать записи базы в полях страницы доступа (рис. 13.6). Таким образом, страницы доступа к данным осуществляют интерфейс между клиентом, сервером и базой данных, размещенной на сервере. Эта база данных не обязательно должна быть базой данных Microsoft Access. Страницы доступа, созданные средствами Microsoft Access, позволяют работать также с базами данных Microsoft SQL Server. Модель: Микропроцессор: Цена: Поставщик: < "Самшит" Поля вывода управления Рис. 13.6. Пример простейшей страницы Макросы и модули. Эти категории объектов предназначены как для автоматиза- ции повторяющихся операций при работе с системой управления базами данных, так и для создания новых функций путем программирования. В СУБД Microsoft Access макросы состоят из последовательности внутренних команд СУБД и явля- ются одним из средств автоматизации работы с базой. Модули создаются средствами внешнего языка программирования, в данном случае языка Visual Basic for Applications. Это одно из средств, с помощью которых разработчик базы может зало- жить в нее нестандартные функциональные возможности, удовлетворить специфи- ческие требования заказчика, повысить быстродействие системы управления, а так- же уровень ее защищенности. Проектирование базы данных Мы лишь рассмотрели основные баз данных и еще не знакомы ни с одной системой управления базами данных, но, тем не менее, поднимаем вопрос о проекти- ровании базы. Это не случайно. Методически правильно начинать работу с каран- дашом и листом бумаги в руках, не используя компьютер. На данном этапе он просто не нужен. Неоптимальные решения и прямые ошибки, заложенные на этапе про- ектирования, впоследствии очень трудно устраняются, поэтому этот этап является основополагающим. Разработка технического задания. Техническое задание на проектирование базы данных должен предоставить заказчик. Однако для этого он должен владеть соот- ветствующей терминологией и знать, хотя бы в общих чертах, технические возмож- ности основных систем управления базами данных. К сожалению, на практике такое положение встречается не всегда. Поэтому обычно используют следующие подходы: • демонстрируют заказчику работу аналогичной базы данных, после чего согласо- вывают спецификацию отличий; • если аналога нет, выясняют круг задач и потребностей заказчика, после чего помогают ему подготовить техническое задание. 3 5 0 Глава Работа с базами данных При подготовке технического задания составляют: • список исходных данных, с которыми работает заказчик; • список выходных данных, которые необходимы заказчику для управления структурой своего предприятия; • список выходных данных, которые не являются необходимыми для заказчика, но которые он должен предоставлять в другие организации (в структуры, в органы статистического учета, прочие административные и конт- ролирующие организации). При этом очень важно не ограничиваться взаимодействием с головным подразде- лением заказчика, а провести обсуждение со всеми службами и подразделениями, которые могут оказаться поставщиками данных в или их потребителями. Так, например, при подготовке базы данных для учета абитуриентов и студентов в выс- шем учебном заведении необходимо не только изучить документооборот ректората и всех деканатов, но и понять, что хотели бы получить от базы данных службы. Следует изучить работу подразделений, распределяющих учебную нагрузку препо- давателей, отвечающих за распределение аудиторного фонда, за проживание студентов в общежитии и других. В расчет должны приниматься и такие службы, как библиотека, отдел кадров и прочие. В момент может выясниться, напри- мер, что администрация библиотеки должна периодически поставлять кому-то отчеты, характеризующие читательскую активность студентов в зависимости от пола, возраста и социального положения. К возможным пожеланиям заказчика следует готовиться на этапе проектирования, до создания базы. Разработка схемы данных Выяснив основную часть данных, которые заказчик потребляет или поставляет, можно приступать к созданию структуры базы, то есть структуры ее основных таблиц. 1. Работа начинается с составления генерального списка полей — он может насчи- тывать десятки и даже сотни позиций. 2. В соответствии с типом данных, размещаемых в каждом поле, определяют наи- более подходящий тип для каждого 3. Далее распределяют поля генерального списка по базовым таблицам. На первом этапе распределение производят по функциональному признаку. Цель — обес- печить, чтобы ввод данных в одну таблицу производился, по возможности, в рамках одного подразделения, а еще лучше — на одном рабочем месте. Наметив столько таблиц, сколько подразделений охватывает база данных, при- ступают к дальнейшему делению таблиц. Критерием необходимости деления является факт множественного повтора данных в соседних записях. рис. показана таблица, у которой в поле Адрес наблюдается повтор данных. Это явное свидетельство того, что таблицу надо поделить на две взаимосвязанных таблицы. 4. В каждой из таблиц намечают ключевое поле. В качестве такового выбирают поле, данные в котором повторяться не могут. Например, для таблицы данных о студентах таким полем может служить индивидуальный шифр студента. Для Формирование баз данных 0 0 0 "Самшит" 123456 Москва ул 15 123-45-67 ТОО "Планета" 111222 Москва ул Промышленная, д 22 111-22-33 ТОО "Паритет" 121212 Москва Заводской проспект, д 144 100-00-00 "Кристина" 135791 Москва Технический проезд, д 4 Рис. 13.7. Если данные в поле начинают повторяться, это признак того, что таблицу следует поделить таблицы, в которой содержатся расписания занятий, такого поля можно и найти, но его можно создать искусственным комбинированием полей «Время занятия» и «Номер аудитории». Эта комбинация неповторима, так как в одной аудитории в одно и то же время не принято проводить два различных занятия. Если в таблице вообще нет никаких полей, которые можно было бы использо- вать как ключевые, всегда можно ввести дополнительное поле типа Счетчик — оно не может содержать повторяющихся данных по определению. 5. С помощью карандаша и бумаги расчерчивают связи между таблицами. рис. 13.8 показан пример взаимосвязи между группой таблиц, составляющих одну базу данных. Такой чертеж называется схемой данных. Существует несколько типов возможных связей между таблицами. Наиболее распространенными являются связи «один ко многим» и «один к одному». Связь между таблицами организуется на основе общего поля, причем в одной из таблиц оно обязательно должно быть ключевым, то есть на стороне «один» должно выступать ключевое поле, содержащее уникальные, неповторяющиеся значения. Значения на стороне «многие» могут повторяться. 352 Глава Работа с базами данных Рис. 13.8. Схема связей между таблицами Рассмотрим таблицу Клиенты (рис. 13.8). Здесь поле Код клиента является клю- чевым. Это понятно, поскольку у каждого клиента должен быть свой уникаль- ный код, идентифицирующий его однозначно. мы рассмотрим таблицу Заказы, то увидим, что в ней код клиента не может быть уникальным, поскольку каждый клиент мог сделать сколь угодно много заказов. На схеме данных эти поля соединены линией связи. С одной стороны эта линия маркирована знаком «1», с другой стороны — значком «бесконечность». Это графический метод изображения связи «один ко многим». Ключевым полем в таблице заказов является Код заказа — он однозначно иден- тифицирует, кто, когда, что заказал и на какую сумму. Здесь же можно узнать, какой сотрудник принял заказ к исполнению. Поскольку один сотрудник может принять множество заказов, поле Код сотрудника в таблице заказов не является ни уникальным, ни ключевым, зато в таблице Сотрудники это уникально. Про подобные таблицы говорят, что они реляционными отношениями. Соответственно, системы управления, способные работать со связанными табли- цами, называют системами управления реляционными базами данных, а схему данных в технической литературе могут называть схемой реляционных отношений. 6. Разработкой схемы данных заканчивается «бумажный» этап работы над техни- ческим предложением. Эту схему можно согласовать с заказчиком, после чего приступать к созданию базы данных. Следует помнить, что по ходу разработки проекта заказчику непременно будут приходить в голову новые идеи. На всех этапах проектирования он стремится охва- тить единой системой все новые и новые подразделения и службы предприятия. Возможность гибкого исполнения его пожеланий во многом определяется квали- фикацией разработчика базы данных. Если схема данных составлена правильно, подключать к базе новые таблицы нетрудно. Если структура базы нерациональна, разработчик может испытать серьезные трудности и войти в противоречия с заказ- чиком. Противоречия исполнителя с заказчиком всегда свидетельствуют о недостаточ- ной квалификации исполнителя. Именно поэтому этап предварительного проекта- Работа с СУБД Microsoft Access 2002 . 3 5 3 рования базы данных следует считать основным. От его успеха зависит, насколько база данных станет удобной и будут ли с ней работать пользователи. Если отмеча- ется, что пользователи базы «саботируют» ее эксплуатацию и предпочитают работать традиционными методами, это говорит не о низкой квалификации пользователей, а о недостаточной квалификации разработчика базы. На этом этапе завершается предварительное проектирование базы данных, и на следующем этапе начинается ее непосредственная разработка. С этого момента сле- дует начать работу с системой управления базами данных. В нашем примере мы рассмотрим СУБД Microsoft Access 2002. |