Реферат на тему:


Воспользуйтесь поиском к примеру Реферат        Грубый поиск Точный поиск






Загрузка...
СОДЕРЖАНИЕ

СОДЕРЖАНИЕ

Введение ..................................................................... 4

1. Постановка задачи ........................................ 9

2. Структура программного комплекса ................ 11

3. Инструкция пользователя ............................... 13

Глава 4. Программный комплекс ................................. 15

Заключение ............................................................... 31

Литература ............................................................. 32

Дополнения ............................................................. 33,34

Введение

База данных, построенная на двумерном файле, является двумерной моделью. Реляционная база данных добавляет третье измерение. Теперь вы можете представить себе ее длину, ширину и глубину. Ряды - это ширина, колонки - это длина, а зависимость - это глубина.

База данных - это совокупность информации, относящейся к определенной теме. Но как организовать эту информацию с максимальной эффективностью? Правильная разработка базы данных - ключ для решения этой задачи.

Таблица - это место, которое прямым или косвенным образом направлена большая часть работы над базой данных. Но есть несколько таблиц, связанных друг с другом в вашей базе данных, еще не означает, что они готовы для функционирования базы данных.

То, что нужно рассмотреть при разработке базы данных, включая:

назначения базы данных

необходимые таблицы и поля

необходимые связи между таблицами

указание, как избежать лишних данных

указание, как убедиться в согласованности данных.

В базе данных есть полезная нормализация данных, которая является процессом упрощения разработки базы данных, целью которого является получение максимальной эффективности и согласованности. Одни говорят, что нормализация - это процесс обнаружения и удаления лишних данных и аномалий в базе данных, связанных с ними. Другие утверждают, что нормализация является процесс разбиения таблиц на мелкие компоненты с целью оптимизации. Некая комбинация этих определений почти верная., Чтобы убедиться в правильности разработки базы данных и структуры таблицы, необходимо избежать двух пороков разработки: избыточности и несогласованности.

Если есть таблица с лишним числом полей или с большим количеством лишних (повторяющиеся) данных - это сигнал, что нужна нормализация. Разбивая таблицы на мелкие таблички и обеспечивая связь между похожими табличками, вы выполняете несколько задач, которые включают избежание данных, повторяющихся как внутри самой таблицы, так и внутри связанных (схожих) табличек:

максимизацию скорости и эффективности вашей базы данных

обеспечения того, что одинаковые данные никогда не будут помещены более чем в одно поле

экономию дискового пространства путем избежания лишних данных

обеспечения согласованности и единообразия данных, будь то входные или выходные данные

создание механизма для поисков по условию в запросах, формах или отчетах.

Если не сделать объединение между таблицами, то эти типы запросов отражать все возможные комбинации из каждой таблицы, которой касается этот запрос. Например, две 60-строчные таблицы, заданные таким образом в запросе, дадут результат размере 3600 строк. Это происходит потому, что 60 на 60 равно 3600. Без объединения или условного оператора where (где) в запросе содержит две или более таблицу, вы легко можете запутаться в результатах. Короче говоря, объединения обычно являются простейшими, наиболее эффективным методом сравнения и связывание таблиц.

Если таблица - душа базы данных, то о поле можно сказать, что это душа таблице. Запись - это просто совокупность полей. Некоторые говорят, что поле - это наименьший элемент базы данных, но вряд ли это определение является наглядным. С другой стороны, то, что поле очень мало по сравнению с размерами современных баз данных, позволяет определить его следующим образом.

Поле - это просто категория или объединения общепринятых значений. Вы не писать название города там, где нужно писать название штата, равно как вы писать фамилию в поле имени. Эти категории должны храниться тщательно, сохраняя точность.

Поскольку поле - это место, где вы рассчитываете, обновляете, изменении, обрабатываете и сравниваете данные, то неудивительно, что Access поддерживает соответствующий набор проверок правильности, которые вы можете применять к полям для сохранения точности. Например, предположим, что вводятся номера социального страхования в таблицу. Если ввести восемь вместо девяти знаков, то необходимо знать, что один знак не хватает. Шаблонное введения Access укажет на это по ходу проверки правильности расстановки тире.

Нормализация поможет вам определить, в каких таблицах размещать какие поля. Здравый смысл подсказывает, что надо содержать в таблице все поля, относящиеся к одному и тому же предмету.

Access позволяет использовать текстовый тип данных для всех полей, если вы этого хотите. Но в данном случае этот подход безрассудный по нескольким причинам. Вы не сможете должным образом сортировать числовые данные, а также посчитать количество дней между датами. И это всего лишь верхушка айсберга.

Поскольку важнейшим компонентом любой базы данных являются сами данные, не следует недооценивать важность ввода данных. Если данные проверены должным образом, количество ошибок сводится к минимуму.

Зачем нужно накладывать столько ограничений на только что созданную вами таблицу? Вы хотите избавиться от ошибок в данных, насколько это возможно. Вы обнаружите, что в Access есть средства проверки данных после введения, но почему бы не проверять их в процессе ввода? Пользователи не получают никаких надоедливых сообщений до тех пор, пока они не введут неправильные данные. Access не позволит осуществить такое введение с теми правилами проверки, которые вы установили. Об этой ошибке будет сообщено пользователю, и он сможет продолжить ввод, когда ошибка будет исправлена.

Хотя нельзя до конца избавиться от ошибок человека, вы можете свести к минимуму шансы появления этих ошибок. Когда происходит ввод больших объемов информации, скорость введения можно увеличить. Например, если оператор по вводу данных вводит номера социального страхования, то автоматическая вставка знаков элементов в поле ввода может увеличить скорость набора. Даже если это увеличит скорость всего лишь на долю секунды для каждой записи, эти судьбы складываются за долгое время набора.

Возвращаясь к первоначальному вопросу, выясним, почему же таблица все-таки душа базы данных. Потому что таблица - это основа всего в базе данных. Запросы, формы, отчеты, макросы и модули - все вертится вокруг таблицы. Так же как таблица должна иметь отношение к одному предмету, база данных должна иметь отношение к одной теме.

В Access добавлен еще одно средство для дальнейшего описания базы данных. Теперь можете объединять в группы таблицы, отчеты и формы, относящиеся к одной и той же или в похожих категорий. Хотя поле-это тоже категория, это широкая категория. Так же как поле категории общепринятых значений, группа Access является категорией общепринятых объектов. Например, вы можете объединить все отчеты, связанные со счетами, в одну

Загрузка...

Страницы: 1 2 3 4