 |
Введите в таблицы исходные данные
|
|
|
|
3.1. Введите исходные данные из первичных документов
3.2. Разработка условий комплексной проверки исходных данных. Такая проверка предназ-начена для поддержки семантической целостности данных. Например, дата окончания института не может быть меньше даты окончания школы. Условное выражение, определяющее семантическую целостность, включает в себя ссылки на поля одной таблицы. Условие на значение для записи можно задать в окне свойств таблицы, вызываемом командой Свойства в меню Вид в режиме конструктора таблицы или из панели инструментов.
Значения свойств Условие на значение (ValidationRule) и Сообщение об ошибке (ValidationText) задаются:
в разделе свойств поля в режиме конструктора таблицы (условие на значение поля);
в окне свойств таблицы, вызываемом командой Свойства в меню Вид в режиме конструктора таблицы (условие на значение записи);
в окне свойств элемента управления в форме;
в макросе или в программе Microsoft Visual Basic. В программе Microsoft Visual Basic значения данных свойств задаются с помощью строковых выражений.
3.3. В режиме конструктора таблиц проверьте введенные данные на семантическую целостность (Правка /Проверка условий).
4. Анализ данных в режиме таблиц (& Работа с данными / Поиск, сортировка и группировка данных )
4.1. Изучите возможности поиска и замены данных, используя все возможные методы
4.2. Изучите применение различных типов фильтрации в таблице.
4.3. Использование сортировки.
4.4. Проведите анализ данных с использованием подтаблиц. Изучите возможностипереключения подтаблиц.. (& Работа с данными / Просмотр данных / Работа с таблицами / Работа с подтаблицами ).
Содержание отчета
Состав разработанной базы данных, включающий перечень разработанных таблиц с атрибутами. Первичный ключ – подчеркнуть.
|
|
|
Состав базы данных
| № | Название таблицы | Названия полей |
| СЛУЖАЩИЙ | #Сл, ФИО, ДатаР, Фото | |
| СПЕКТАКЛЬ | #Сп, Назв, Жанр, Кмпз | |
| РЕПЕРТУАР | # Р, Дата, Время, #Сп | |
| АКТЕР | #Актер, Разряд, Звание |
Для каждой созданной таблицы составьте описание характеристик атрибутов по предлагаемой ниже форме.
Описание характеристик атрибутов
| № | Имя атрибута | А1 | А2 | А3 | А4 | А5 | А6 | А7 |
| #Сл | Сч | дц | да | |||||
| ФИО | Текст | да | д/н | |||||
| ДатаР | Д/В | Кфд | Дата рождения | да | ||||
| Телеф | Текст | &&-&&-&& | Телефон | |||||
| Фото | OLE |
где
Тип данных (А1).
Размер поля (А2).
Формат вывода значений данного поля (А3).
Подпись поля в форме (А4).
Значение по умолчанию (А5).
Обязательное поле (А6).
Индексированное поле (А7).
Сформулируйте ограничения (правила валидации) для полей и записей каждой таблицы.
Правилавалидации (ValidationRule)
Для полей
| № | Таблица | Поле | Условие на значение | Сообщение об ошибке |
| Репертуар | Дата | <Date() | ||
| Служащий | Дата рождения | >=#01.01.1920# And <#01.01.1990# | Ошибка! Очень молод или очень стар! | |
Для записей
| № | Таблица | Условие на значение | Сообщение об ошибке |
| Актер | Not ([Разряд]<14 And Not ([Звание]="")) | Разряд актера не соответствует его званию | |
По предлагаемой ниже форме создайте описание подстановок.
Описаниеподстановок
| Таблица | Исходное поле | Поле подстановки | Тип элемента управления | Тип источника строк | Источник строк |
| Спектакль | Жанр | Жанр | Список | Список значений | Балет; Опера; Оперетта |
| Роль | #Сл | ФИО актера | Поле со списком | Сохраненный запрос | з_Служащий |
| Роль | #Сп | Спектакль | Поле со списком | Инструкция SQL | SELECT Спектакль.[#Сп], Спектакль.Название FROM Спектакль; |
| и т.д. |
|
|
|
Описание связей между таблицами. Приведите схему разработанной базы данных (при открытом окне схемы Файл/Печать схемы данных).
4. Контрольные вопросы
1) Назовите три метода создания БД в Microsoft Access
Назовите основные режимы работы с таблицами. Как перейти из одного режим в другой?
2) Какие типы объединения записей таблиц (параметры объединения) существуют? В чем их отличие?
3) Какие два инструмента помогают усовершенствовать структуру базы данных?
4) Какое отношение в Microsoft Access называется неопределенным? Как оно отображается в схеме базы данных?
5) Как поддерживается целостность данных в таблицах в Microsoft Access?
6) На примере разрабатываемой БД продемонстрируйте каскадное удаление и обновление.
7) Можно ли установить связи между несколькими полями?
8) Как создаются индексы для одного поля, составной индекс?
9) Как установить формат отображения для данных в поле или элементе управления? Что такое собственный формат?
10) Как создаются в таблице поля со списком подстановок или списком значений в режиме таблиц?
11) Что происходит при импортировании и связывании данных?
12) Как сохранить фильтр, чтобы при повторном открытии таблицы или формы можно снова применить сохраненный фильтр?
13) Перечислите основные свойства таблицы и объясните их назначение.
14) Как распечатать схему базы данных?
15) Как автоматически устранить ошибки, вызванные переименованием форм, отчетов, таблиц, запросов, полей, текстовых полей и других элементов управления в базах данных Microsoft Access?
16) Как предотвратить ввод в таблицу повторяющихся значений?
17) Как закрепить один или несколько столбцов (полей) объекта в режиме таблицы так, чтобы они располагались в левой части таблицы и отображались на экране независимо от прокрутки?
18) В чем состоит различие между значением Null и пустой строкой?
19) Для типа данных Текстовый объясните назначение таки свойств поля как Пустые строки, Сжатие Юникод.
20) Как отсортировать данные по нескольким полям?
21) Какие способы проверки условий на значения данных в программах вы знаете?
22) Объясните назначение пункта меню Вид|Зависимости объектов (при выделенном объекте). Зависимости объектов также можно вызвать из области задач.
|
|
|
23) Как используется автозамена имен? Назовите три режима работы автозамены.
24) В чем различие межу маской ввода и форматом поля?
25) Как перенести данные из предыдущей записи в следующую?
26) Как можно скрыть таблицу, чтобы она не отображалась в окне базы данных?
Дополнительное задание
1. Автоматизировать выполнение операций импорта путем создания макроса или создания процедуры Microsoft Visual Basic для приложений. Это бывает полезно при импорте данных по определенному расписанию или при наличии нестандартных или сложных требований к импорту данных. Работа с данными /Работа с внешними данными/ Автоматизация импорта, экспорта и связывания данных
2. Разработайте спецификацию импорта/экспорта при неоднократном выполнении импорта в одну и ту же таблицу, экспорта в один и тот же файл или для автоматизации процесса импорта или экспорта.
Полезные ссылки
1. Изменение начального значения поля счетчика
2. Установка числа десятичных разрядов, отображаемых в поле или элементе управления
3. Печать схемы базы данных или объекта базы данных
4. Автоматическое устранение ошибок, вызванных переименованием полей
ПРИЛОЖЕНИЕ
Содержание
Поля, которые должны быть в таблицах
Работа со смарт-тегами в Microsoft Access
Повышение быстродействия Microsoft Access
Новиков Сергей
Поля, которые должны быть в таблицах
Каждая таблица должна иметь поле первичного ключа для уникальной идентификации каждой записи и это поле должно быть первым в таблице. Обычно это поле типа "Счетчик" (длинное цело индексированное без повторений с авто-инкрементом). Я рекомендую использовать для поля уникального ключа именно такой тип данных (если это возможно).
Так же весьма полезно, если в таблице присутствуют следующие поля:
ID_StateRecord - это целое поле, в котором по-умолчанию находится 0. Определяет "состояние" записи. Если в этом поле отрицательное значение, то запись считается "удаленной". -1 значит "Удалено", а -2 - "Удалено вместе с "родительской" записью". Процедура каскадного "удаления" записей будет рассмотрена ниже.
|
|
|
- DateCreation - поле типа Дата, в котором по умолчанию содержится дата создания записи. Удобно иметь это поле, чтобы знать, когда запись была создана.
- UserCreation - текстовое поле, в которое необходимо заносить имя пользователя, создавшего запись. Удобно иметь это поле, чтобы знать, кем запись была создана. Заполнять это поле придется программно.
Расположений полей в таблицах
Я советую располагать поля в таблице следующим образом: первым полем должно быть ключевое поле, вторым - поле ID_StateRecord, далее нужно располагать поля, участвующие в связях с другими таблицами, потом остальные поля, предпоследним полем должно быть поле DateCreation, и последним - UserCreation.
Вообще-то без разницы, в каком порядке в таблице находятся поля, но вышеперечисленный порядок лично для меня является самым удобным.
"Нулевая" запись
Каждая таблица по возможности должна иметь запись, в которой значение, содержащееся в ключевом поле (далее будем считать, что ключевое поле имеет типа "Счетчик") равно нулю. Попробую объяснить, для чего это может быть полезно. Я, например, отношусь к "нулевой" записи как к записи, несущий следующий смысл: "Не введено". Для таблицы как таковой это особо не важно, но если эта таблица участвует в связях "один-ко-многим" с другими таблицами со стороны "один", то в связных таблицах если в поле связи стоит 0, то это значит: "Не введено".
Например, если есть талицы tbl_Cities (города) и tbl_Countries (страны) и таблица tbl_Countries имеет ключевое поле ID_Country и "нулевую" запись, а эти таблицы связаны по ключевому полю ID_Country (каждый город находиться в определенной стране), то при вводе нового города это поле в этой таблице по умолчанию должно быть равно нулю, т.е. ссылаться на "нулевую" запись в таблице стран. Это будет означать, что для этого города еще не определена страна. При этом не будет выскакивать ошибки типа "Добавление невозможно, так как отсутствует связная запись"
Реализация этой идеи с полем типа "Счетчик" стала возможна благодаря интересной особенности поля такого типа: при программном создании записи значение такого поля можно задавать самостоятельно.
"ND"-запрос
"ND"-запрос - это такой запрос, который отображает все не удаленные записи в таблице. ("ND" значит "Not Deleted", то есть "не удаленные"). В самой простой ситуации это SELECT по всей таблице без каких либо условий. Если таблица имеет поле ID_StateRecord, то SQL для "ND"-запроса выглядит так: SELECT * FROM tbl_MyTable WHERE ID_StateRecord >=0. При использовании функции каскадного изменения состояния записей (псевдоудаления, когда при необходимости удаления запись не удаляется физически, а "помечается" как удаленная) этот запрос будет возвращать все не удаленные записи.
|
|
|
При наличии для таблицы "ND"-запроса ВСЯ последующая работа с данными этой таблицы должна происходить ТОЛЬКО через этот запрос.
Каждая таблица должна иметь свой "ND"-запрос с префиксом qryND_
Я вообще советую работать с таблицами ТОЛЬКО через запросы, и "ND"-запрос для этого подходит идеально.
"List"-запрос
"List"-запрос - это запрос, построенный на основе одного или нескольких запросов (обычно это "ND"-запросы), содержащий в себе необходимые поля для создания "List"-формы. Что из себя представляет "List"-форма будет рассказано ниже.
"Локальная" таблица
Что такое "локальная" таблица я довольно подробно описывал в статье «Использование локальной таблицы в качестве хранилища значений элементов управления формы для условий отбора в запросах, или Как избавиться от ссылок на формы путем написания нескольких универсальных функций», так что скажу только, что в Мастере Универсального Интерфейса "локальная" таблица и функции работы с такой таблицей претерпели некоторые изменения. "Локальная" таблица необходима для работы "Get", "Edit" и "List"-форм. И не только. Поэтому создать для своей базы "локальную" талицу я советую в первую очередь.
"Журнальные" таблицы
В Access без использования архитектуры "клинт-сервер" невозможно "стандартными" методами вести журнал изменения записей в таблицах. А хотелось-бы. Для чего - и так понятно. Имея такой журнал, где "все ходы записаны" можно узнать, например, кто когда "срукосуйничал". У меня было не один раз были случаи чудесного излечения амнезии у пользователей, которые кричали мне что мол "я никогда в жизни не мог эти данные сюда внести". Когда говоришь ему, что "сделал ты это такого-то числа во столько-то часов столько-то минут столько-то секунд из-под такого-то АРМа в такой-то форме, сидя за такой-то машиной и изменил ты такие-то поля с таких-то на такие-то значения" - сразу амнезия проходит. Можно сделать "откат" определенных изменений. И т.д. и т.п.
Для начала нам нужна таблица, в которых будет храниться вышеописанная полезная информация. Таких таблиц нам нужно 4: в одной будет вестись журнал событий (в какой таблице в какой записи кем-когда-откуда были произведены изменения/добавления/удаления), в другой - собственно список полей и значений этих полей (что было - что стало) для каждой записи первой таблицы. И еще две таблички будут содержать список событий, которые могут произойти в таблице (Создание новой записи, Изменение записи, Удаление записи). Рассмотрим первые 2 таблицы.
| tbl_Journal | ||
| Таблица журнала событий | ||
| Поле | Тип поля | Описание |
| ID_Journal | Счетчик, ключ | Идентификатор записи |
| ID_StateRecord | Long | см. выше про поле ID_StateRecord |
| ParentIDJournal | Long | Идентификатор "родительской" записи в этой же таблице |
| ID_JournalType | Long | Тип события (1 -создание, 2- удаления, 3 -изменение) |
| TableName | Text | Имя таблицы, для которой произошло событие |
| KeyName | Text | Имя ключевого поля таблицы TableName |
| KeyValue | Long | Значение поля KeyName таблицы TableName. (Поскольку поле KeyName являеться ключевым для таблицы TableName, то значение поля KeyValueоднозначно определяет запись, для которой произошло событие). |
| MachineName | Text | Имя компьютера, на котором произошло событие (чтобы знать с какого компа были совершены действия). |
| FormName | Text | Имя формы, в которой произошло событие. |
| AppName | Text | Имя и путь к файлу БД, в котором произошло событие. |
| DateCreation | Date | Когда создана запись. (см. выше про поле DateCreation) |
| UserCreation | Text | Кем создана запись (см. выше про поле UserCreation) |
Например имея в таблице tbl_Journal запись, где, например:
ID_Journal = 123
ID_StateRecord = 0
ParentIDJournal = 0
ID_JournalType = 3
TableName = "tbl_MyTable"
KeyName = "ID_MyTable"
KeyValue = 593
MachineName = "NINA"
FormName = "frmEdit_MyTable"
AppName = "C:\MyBase\MyBase97.mdb"
DateCreation = "12.09.2002 17:43:32"
UserCreation = "Vova"
...а в таблице tbl_JournalEvents запись:
ID_JournalEvent = 789
ID_StateRecord = 0
ID_Journal = 123
ID_JournalEventType = 3
ParentIDJournalEvent = 0
JournalEventMemo1 = "MyField"
JournalEventMemo2 = "Кое-что"
JournalEventMemo3 = "Что-нибудь"
JournalEventMemo4 = ""
DateCreation = "12.09.2002 17:43:32"
UserCreation = "Vova"
... можно сказать, что 12-го сентября 2002 года в 17:43:32 пользователь Vova, работая за машиной NINA с базой C:\MyBase\MyBase97.mdb в форме frmEdit_MyTable изменил в таблице tbl_MyTable (у которой ключевое поле ID_MyTable) в записи, у которой ID_MyTable = 593 значение поля MyField с "Кое-что" на "Что-нибудь". Такая информация иногда бывает ой-как нужна!
Теперь давайте разберемся, что нужно для того, чтобы такая полезная информация в этих таблицах появлялась. Для этого сначала нам необходимо создать "журнальные" таблицы и функции для работы с "журнальными" таблицами. Это умеет делать Мастер. При этом у вас в базе появится 4 вышеописанных таблицы, модуль mdl_Journal с необходимым набором функций и 2 модуля класса: class_Database и class_Recordset, которые имеют тут же функциональность, что и объекты Database и Recordset, но "умеют" отслеживать изменения в таблицах.
Для того, чтобы в какой-либо форме происходило отслеживание изменений в ее модуль надо добавить блок кода из модуля mdl_Journal (там он находится в начале модуля и закомментирован. Комментарии, понятно дело, в модуле формы надо убрать). Этот код универсален и будет работать для любой формы независимо от ее источника данных.
С формами разобрались. Теперь надо разобраться с программным изменением записей. Для этого нам потребуеться класс class_Recordset. Работать с ним надо следующим образом: создавать экземпляр класса, инициализировать его и вызывать методы AddNew, Edit, Update, MoveFirst и т.п. уже для этого класса, а не для рекордсета, которым он был инициализирован. Вот как должен выглядеть код ДО и ПОСЛЕ внесения необходимых изменений:
| ДО |
| Dim rst As Recordset Set rst = CurrentDb.OpenRecordset("qryND_MyTable", dbOpenDynaset) rst.AddNew rst!MyField = "Кое-что" rst!MyFieldAmount = 0 rst!UserCreation = AsCurrentUser() rst.Update |
| ПОСЛЕ |
| Dim rst As Recordset Dim clrst As New class_Recordset Set rst = CurrentDb.OpenRecordset("qryND_MyTable", dbOpenDynaset) clrst.Initialize rst clrst.AddNew rst!MyField = "Кое-что" rst!MyFieldAmount = 0 rst!UserCreation = AsCurrentUser() clrst.Update |
Вот пока и все. Сейчас работаю над процедурой автоматического "отката" и над тем, чтобы класс class_Database использовать для отвлеживания изменений при программном выполнении запросов на обновление/добавление/удаление. Чтобы вместо CurrentDb.Execute "DELETE * FROM tbl_MyTable" можно было написать clDb.Execute "DELETE * FROM tbl_MyTable" - и это уже бы поддерживало отслеживание изменений. Но это в будущем.
|
|
|
