Этап логического проектирования бд реферат
Обновлено: 07.07.2024
Логическое проектирование базы данных – это процесс создания модели используемой на предприятии информации на основе выбранной модели организации данных, но без учета типа целевой СУБД и других физических аспектов реализации.
Второй этап проектирования базы данных называется логическим проектированием базы данных. Его цель состоит в создании логической модели данных для исследуемой части предприятия. Концептуальная модель данных, созданная на предыдущем этапе, уточняется и преобразуется в логическую модель данных. Логическая модель данных учитывает особенности выбранной модели организации данных в целевой СУБД (например, реляционная модель).
Если концептуальная модель данных не зависит от любых физических аспектов реализации, то логическая модель данных создается на основе выбранной модели организации данных целевой СУБД. Иначе говоря, на этом этапе уже должно быть известно, какая СУБД будет использоваться в качестве целевой — реляционная, сетевая, иерархическая или объектно-ориентированная. Однако на этом этапе игнорируются все остальные характеристики выбранной СУБД, например, любые особенности физической организации ее структур хранения данных и построения индексов.
В процессе разработки логическая модель данных постоянно тестируется и проверяется на соответствие требованиям пользователей.
Созданная логическая модель данных является источником информации для этапа физического проектирования и обеспечивает разработчика физической базы данных средствами поиска компромиссов, необходимых для достижения поставленных целей, что очень важно для эффективного проектирования. Логическая модель данных играет также важную роль на этапе эксплуатации и сопровождения уже готовой системы. При правильно организованном сопровождении поддерживаемая в актуальном состоянии модель данных позволяет точно и наглядно представить любые вносимые в базу данных изменения, а также оценить их влияние на прикладные программы и использование данных, уже имеющихся в базе. Физическое проектирование базы данных - процесс подготовки описания реализации базы данных на вторичных запоминающих устройствах; на этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты.
проблема структуризации данных, на ней мы сосредоточим основное внимание.
При проектировании структур д анн ых для автоматизированных систем
1. Сбор информации об объектах решаемой задачи в рамках одной таблицы
(одного отношения) и последующая декомпозиция ее на несколько
взаимосвязанных таблиц на основе процедуры нормализации отношений.
2. Формулирование знаний о системе (определение типов исходных данных и
их взаимосвязей) и требований к обработке данных, получение с помощью CASE-
систе-мы (системы автоматизации проектирования и разработки баз данных)
готовой схемы БД или даже готовой прикладной информационной системы.
3. Ст руктурирование информации для использования в информационной
системе в процессе проведения систем ного анализа на основе совокупности
Базы данных— это компьютеризированная система хранения записей, т.е.
компьютеризированная система, основное назначение которой — хранить
информацию, предоставляя пользователям средства ее извлечения и модифика -
ции. К информ ации может относиться все, что заслуживает внимания отдельного
пользователя или организации, использующей систему, иначе г оворя, все
необходимое для текущей работы данного пользователя или предприятия.
На рис. 1 показана весьма упрошенная схема системы баз данных. Здесь
отражено четыре главных компонента системы, а именно: данные, аппаратное
обеспечение, программное обеспечение и пользователи. Каждый из этих
Системы с базами данных существуют как на самых малых компьютерах, так
и на крупнейших мэйнфреймах. Нет необходимости говорить, что
предоставляемые каж дой конкретной системой средства в некоторой мере зависят
от мощности и возможностей базовой машины. В частности, системы на больших
машинах ("большие системы"), в основном, многопользовательские, тогда как
системы на малых машинах ("малые сис темы"), как правило,
однопользовательские. Однопользоват ельская система ( single-user system) — это
система, в которой одновременно к базе данных может по лучить доступ не более
одного пользователя, а многопользовательская систем а ( multi-user system) — это
такая система, в которой к базе данных могут получить доступ сразу не сколько
пользователей. Как и в схем е на рис. 1, исходя из соображений общности, мы
обычно будем подразумевать именно второй вид систем, хотя, с точки зрения
пользователей, между этими системами фактически не существует большого
различия. Основная задача большинства многопользовательских систем—
позволить каж дому отдельному пользователю работать с ней так, как он мог бы
работать с однопользовательской системой. Различия между этими двумя видами
систем проявляются в их внутренней структуре, и потому практически не видны
К аппаратному обеспечению системы относится следующее.
• Тома вторичной (внешней) памяти (обычно это магнитные диски),
используемые для хранения информации, а также соответствующие устройства
ввода-вывода (дисководы и т.п.), контроллеры устройств, каналы ввода-вывода и
• Аппаратный процессор (или процессоры) вместе с основной (первичной)
памятью, предназначенные для поддержки работы программного обеспечения
Между собственно физической базой данных (т.е. данными, которые реально
хранятся) и пользователями сист емы располагает ся уровень программного
обеспечения, который можно называть по-разному: менеджер базы данных
(database manager), сервер базы данных (database server) или, что более
привычно, система управления базами данных, СУБД (database management
system — DBM S). Все запросы пользо вателей на доступ к базе данных
обрабатываются СУБД. Все имеющиеся средства до бавления файлов (или
таблиц), выборки и обновления данных в этих файлах или таб лицах также
предоставляет СУБД. Основная задача СУБД — предоставить пользова телю базы
данных возможность работать с ней, не вникая в детали на уровне аппа ратного
обеспечения. ( Пользователь СУБД более отстранен от этих деталей, чем при -
кладной программист, применяющий языковую среду программирования.)
Иными словами, СУБД позволяет конечному пользователю рассматривать базу
данных как объект более высокого уровня по сравнению с аппаратным
обеспечением, а также предоставляет в его распоряжение набор операций,
выражаемых в терминах языка вы сокого уровня (например, набор операций,
Пользователей можно разделить на три большие и отчасти перекрывающиеся
• Первая группа — прикладные программисты , которые отвечают за
написание прикладных программ, использующих базу данных. Для этих целей
применимы такие языки, как COBOL, PL/I, C++, Java или какой-нибудь
высокоуровневый язык четвертого поколения. Прикладные программы получают
доступ к базе данных посредством выдачи соответствующего запроса к СУБД
• Вторая группа — конечные п ользо ватели , которые работают с системой
баз данных непосредственно через рабочую станцию или терминал. Конечный
пользователь может получать доступ к базе данных, применяя одно из
интерактивных приложений, упомянутых выше, или же интерфейс,
интегрированный в про граммное обеспечение самой СУБД. Безусловно,
подобный интерфейс также под держивается интерактивными приложениями,
однако эти приложения не создаются пользователями-программистами, а
являются встроенным и в СУБД. Большин ство СУБД включает по крайней мере
одно такое встроенное приложение, а именно — процессор языка запросов,
позволяющий пользов ателю в диалоговом режиме вводить запросы к базе данных
(их часто иначе называют операторами (statement) или командами ( commands)),
например S ELECT или INSERT. Язык SQL — типичный пример языка запросов
Структурой системы называется её расчленение на группы элементов с
указанием связей между ними, неизменное на всё время рассмотрения и дающее
представление о системе в целом. Иначе можно сказать, что структура это
множество элементов и связей м ежду ними, принадлежащее определённому
уровню декомпозиции. Важнейшим стимулом и сутью декомпозиции является
упрощение системы, слишком сложной для рассмотрения целиком.
Архитектура ANSI/SPARC включает три уровня: внутренний, внешний и
концептуальный (рис. 2). В общих чертах они представляют собой следующее.
• Внутренний уро вень (также называемый физическим) наиболее близок к
физическому хранилищу информации, т.е. связан со способ ами сохранения
• Внешний уро вень (также называемый пользовательским логическим)
наиболее близок к пользователя м, т.е. связан со способами представления данных
• Концептуальный уровень (также называемый общим логическим или
просто логическим) является "промежуточным" уровнем между двумя первыми.
Если внешний уровень связан с индивидуальными представлениями
пользователей, тс концептуальный уровень связан с обобщенным представлением
пользователей. Иначе говоря , может существовать несколько внешних
представлений, каждое из которых со стоит из более или менее абстрактного
представления определенной части базы данных и только одно концептуальное
представление, состоящее из абстрактного представления базы данных в целом.
(Вспомните, что большинство пользователей интересует не вся база данных, а
лишь ее некоторая ограниченная часть.) Также существует единственное
внутреннее представление, отражающее способ физического хранения всей базы
Для лучшего понимания этих идей рассмотрим пример, представленный на
рис. 3. Здесь отображено концептуальное представление простой базы данных о
персонале, а также соответствующие ему внутреннее и два внешних
представления (одно — для поль зователя, прим еняющего язык PL/I, а другое —
для пользователя, применяющего язык COBOL). Конечно, этот пример полностью
гипотетичен и мало похож на реальные сис темы, поскольку в нем умышленно
Рис. 3 Пример трех уровней представления базы данных
Рассматриваемый здесь пример нуждается в пояснениях.
На концептуальном уровне база данных содержит информацию о типе
сущности с именем EMPLOYEE (служащий). Каждый экземпляр
сущности EMPLOYEE включает атрибуты номера служащего
EMPLOYEE_NUMBER (длиной шесть символов), номера отдела
DEPARTMENT_NUMBER (длиной четыре символа) и зарплаты
На внутреннем уровне служащие представлены типом хранимой
записи STORED_EMP, длина которой составляет 20 байт. Запись
STORED_EMP содержит че тыре хранимых поля: шестибайтовый префикс
(возможно, содержащий управляющую информацию, такую как флаги или
указатели) и три поля данных, соот ветствующие трем свойствам
сущности, которая представляет служащего. Кроме того, записи STORED
Пользователь, применяющий язык PL /I, имеет дело с соответствующим
внешним представлением базы данных. В нем каждый сотрудник
представлен записью на языке PL/I, содержащей два поля (номера отделов
не представляют интереса для данного пользователя, поэтому в
представлении они опущены ). Тип записи определен с помощью обычной
Аналогично пользователь, прим еняющий язык COBOL, имеет дело с
собственным внешним представлением базы данных, в котором каждый
сотрудник представлен записью на языке COBOL, содержащей, опять ж е,
два поля (в данном случае опущен размер оклада). Тип записи определен с
помощью обычного описания на языке COBOL в соответствии с
Нужно обратить внимание, что в каждом случае соответствующие элементы
данных могут меть различные им ена. Например, к номеру сотрудника
обращаются, как к полю EMPt в представлении для языка PL/I и как к полю
EMPNO в представлении для языка COBOL. Этот же атрибут в концептуальном
представлении имеет имя E MP LOYEE_NUMBER, а во внутреннем представлении
Например, она должна знать, что поле EMPNO в представлении для языка
COBOL образовано из концептуального поля EMPLOYEE NUMBER, которое, в
Такие соответствия, или отображения, явно не показаны на рис. 3.
В данном случае не имеет особого значения, является ли рассматриваемая
Внешний уровень — это индивидуальный уровень пользователя. Как было
сказано главе 1, пользователь может быть прикладным программистом или
конечным пользователем с любым уровнем профессиональной подготовки.
(Особое место среди пользователей занимает адм инистратор базы данных (АБД).
В отличие от остальных пользователей, АБД интересует также концептуальный и
внутренний уровни. Об этом еще будет говориться в следующих двух разделах.)
Для прикладного программиста это либо один из распространенных
языков программирования (например, PL/I, C++ или Java), либо
специальный язык рассматриваемой системы. Такие оригинальные языки
называют языками четвертого поколения на том (не вполне
определенном!) основании, что машинный код, язык ассемблера и такие
языки, как PL /I, можно считать языками трех первых "поколений", а
оригинальные языки модернизированы по сравнению с языкам третьего
поколения так же, как языки третьего поколения улучшены по сравнению
Для конечного пользователя это или специальный язык запросов, или язык
специального назначения, который может быть основан на использовании
форм и меню, разработан специально с учетом требований пол ьзователя и
интерактивно поддерживаться некоторым оперативным приложением.
Для нашего обсуждения важно, что все эти языки включают подъязык
данных, т.е. подмножество операторов всего языка, связанное только с
объектами баз дан ных и операциям и с ними. Иначе говоря, подъязык данных
встроен в базовый язык, который дополнительно обеспечивает различные не
связанные с базами дан ных возможности (такие, как локальные (временные)
переменные, вычислительные операции, логические операции и т.д.). Система
может поддерживать любое количе ство базовых языков и любое количество
подъязыков данных. Однако существует один язык, который поддерживается
практически всеми сегодняшними систем ами. Это язык SQL. Большинство систем
позволяет использовать язык SQL и интерактивно, как самостоятельный язык
запросов, и посредством внедрения его операторов в другие языки
Хотя с точки зрения архитектуры удобно различать подъязык данных и
включающий его базовый язык, на практике они могут быть неразличимы
настолько, насколько это имеет отношение к пользователю. Безусловно, с точки
зрения пользователя пред почтительнее, чтобы они были неразличимы. Е сли они
неразличимы или трудноразли чимы, их называют сильно связанными. Если они
ясно и легко различаются, говорят, что эти языки сл або связ аны. В то время как
некоторые коммерческие. системы (особенно объектные системы) поддерживают
сильную связь, большин ство систем, в частности системы SQL, обычно
поддерживают лишь слабую свя зь. Системы с сильной связью м огли б ы
предоставить пользователю более унифициро ванный набор возможностей, но,
очевидно, они требуют боль ше усилий со стороны системных проектировщиков и
разработчиков, которые, вероятно, рассчитывают на сохранение статус-кво.
В принципе, любой подъязык данных является на самом деле ком бинацией
по крайней мере двух подчиненных языков — языка определения данных (data
definition language — DDL), который поддерживает определения или объявления
объектов базы данных, и языка обработки да нных (data manipulation language —
DML), который поддерживает операции с такими объектами или их обработку.
Например, рассмотрим пользователя языка PL/I (см. рис. 3). Подъязык данных
этого пользователя включает определенные средства языка PL/I, применяемые
Язык определения данных включает некоторые описательные структуры
языка PL/I, необходимые для объявления объектов базы данных. Это сам
оператор DECLARE (DCL), определенные типы данных языка PL/I, а также
возможные специальные дополнения для языка PL/I , предназначенные для
поддержки новых объектов, которые не поддерживаются существующей
Язык обработки данных состоит из тех выполняемых операторов языка PL/
I, которые передают информацию в базу данных и из нее; опять же,
Отдельного пользователя интересу ет лишь некоторая часть всей базы
данных. Кроме того, представление пользователя об этой части будет, безусловно,
чем-то абстрактным по сравнению с выбранным способом физического хранения
данных. В соответствии с терминологией ANSI/SPARC представление отдельного
пользователя называется внешним представлением. Таким образом, внешнее
представление— это содержимое базы данных, каким его видит определенный
пользователь (т.е. для каждого пользователя знешнее представление и есть та
база данных, с которой он работает). Например, пользователь из отдела кадров
может рассматривать базу данных как набор записей с информацией об отделах
плюс набор записей с информацией о служащих и ничего не знать о записях с
информацией о материалах и их поставщиках, с которыми рабо тают пользователи
В общем случае внешнее представление состоит из некоторого множества
экземпляров каждого из м ногих типов внешних записей (которые вовсе не
обязательно должны совпадать с хранимыми записями). Предоставляемый в
распоряжение пользователя подъязык данных всегда определяется в терминах
внешних записей. Напри мер, операция выборки языка обработки данных
осуществляет выборку экземпляров внешних, а не хранимых записей.
Каждое внешнее представление определяется посредством внешн е й схемы,
которая, в основном, состоит из определений записей каждого из типов, присутст -
вующих в этом внешнем представлении (см. рис. 3). Внешняя схема записывает ся
с помощью языка определения данных, являющегося подмножеством подъязы ка
данных пользователя. (Поэтому язык определения данных иногда называют
внешним языком определения данных.) Например, тип внешней записи о работни -
ке можно определить как шестисим вольное поле с номером работника, плюс поле
из пяти десятичных цифр, предназначенное для его зарплаты, и т.д. Кроме того,
может потребоваться определить отображен ие между внешней и исходной
Рис. 4 Детальная схема архитектуры системы баз данных
Концептуальное представление — это представление всей информации
базы данных в несколько более абстрактной форме (как и в случае внешнего
представления по сравнению с физическим способом хранения данных. Однако
концептуальное представление существенно отличается от представления данных
каким-либо отдельным пользователем. Вообще говоря, концептуальное
представление — это представление данных такими, какими они являются на
самом деле, а не такими, какими их вынужден видеть пользователь в рамках,
например, определенного языка или используемого ап паратного обеспечения.
Концептуальное представление состоит из некоторого множества
экземпляров каждого из существующих типов концептуальных зап исей.
Например, оно может состоять из набора экземпляров записей, содержащих
информацию об отделах, набора экземпляров записей, содержащих инф ор мацию
Наиболее важным этапом проектирования базы данных является само его начало и мозговой штурм. Это то, что позволяет любому разработчику получить всю необходимую информацию заранее и реализовывать задуманное по мере необходимости. Только имея всю необходимую информацию для проектирования, можно создать эффективную базу данных с правильно связанными таблицами.
Любая база данных должна быть эффективной и масштабируемой. Данные постоянно редактируются, добавляются, удаляются, поэтому важным будет содержать базу данных организованной таким образом, чтобы поддерживать этот постоянно изменяющийся набор данных.
Содержание
Работа содержит 1 файл
Информатика.doc
федерального государственного бюджетного образовательного учреждения
высшего профессионального образования «Российский государственный
(Филиал РГГУ в г. Астрахани)
Яхъяева Халида Азатовна
Этапы проектирования базы данных
ГЛАВА II. ЭТАПЫ БАЗЫ ДАННЫХ ……………………. 6
ГЛАВА III. СУБД Microsoft Access……………………. 10
СПИСОК ЛИТЕРАТУРЫ …………………………………. 13
Информатика (от информация и автоматика) — наука о методах и процессах сбора, хранения, обработки, анализа и оценивания информации, обеспечивающих возможность её использования для принятия решений. Она включает дисциплины, относящиеся к обработке информации в вычислительных машинах и вычислительных сетях: как абстрактные, вроде анализа алгоритмов, так и довольно конкретные, например, разработка языков программирования.
Темами исследований в информатике являются вопросы: что можно, а что нельзя реализовать в программах и базах данных (теория вычислимости и искусственный интеллект), каким образом можно решать специфические вычислительные и информационные задачи с максимальной эффективностью (теория сложности вычислений), в каком виде следует хранить и восстанавливать информацию специфического вида (структуры и базы данных), как программы и люди должны взаимодействовать друг с другом (пользовательский интерфейс и языки программирования и представление знаний) и т. п.
База данных — представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ) (Гражданский кодекс РФ, ст. 1260).
Система управления базами данных - это комплекс программных и языковых средств, необходимых для создания баз данных, поддержания их в актуальном состоянии и организации поиска в них необходимой информации.
На настоящий момент существует множество различных СУБД. Наиболее широкую известность получили такие как Dbase, Clipper, FoxPro, Paradox, Microsoft Access.
Объектами обработки СУБД являются следующие информационные единицы.
Поле - элементарная единица логической организации данных, которая соответствует неделимой единице информации - реквизиту.
Запись - совокупность логически связанных полей.
Экземпляр записи - отдельная реализация записи, содержащая конкретные значения ее полей.
Таблица - упорядоченная структура, состоящая из конечного набора однотипных записей.
Первичный ключ - поле или группа полей, позволяющие однозначным образом определить каждую строку в таблице. Первичный ключ должен обладать двумя свойствами:
- Однозначная идентификация записи: запись должна однозначно определяться значением ключа.
- Отсутствие избыточности: никакое поле нельзя удалить из ключа, не нарушая при этом свойства однозначной идентификации.
Кроме первичного, могут использоваться так называемые простые (или вторичные) ключи таблицы. Простых ключей может быть множество. Они используются при упорядочивании (индексировании) таблиц.
ГЛАВА II. Этапы базы данных.
При разработке БД можно выделить следующие этапы работы.
I этап. Постановка задачи.
На этом этапе формируется задание по созданию БД. В нем подробно описывается состав базы, назначение и цели ее создания, а также перечисляется, какие виды работ предполагается осуществлять в этой базе данных (отбор, дополнение, изменение данных, печать или вывод отчета и т. д).
II этап. Анализ объекта.
На этом этапе рассматривается, из каких объектов может состоять БД, каковы свойства этих объектов. После разбиения БД на отдельные объекты необходимо рассмотреть свойства каждого из этих объектов, или, другими словами, установить, какими параметрами описывается каждый объект. Все эти сведения можно располагать в виде отдельных записей и таблиц. Далее необходимо рассмотреть тип данных каждой отдельной единицы записи. Сведения о типах данных также следует занести в составляемую таблицу.
III этап. Синтез модели.
На этом этапе по проведенному выше анализу необходимо выбрать определенную модель БД. Далее рассматриваются достоинства и недостатки каждой модели и сопоставляются с требованиями и задачами создаваемой БД. После такого анализа выбирают ту модель, которая сможет максимально обеспечить реализацию поставленной задачи. После выбора модели необходимо нарисовать ее схему с указанием связей между таблицами или узлами.
IV этап. Выбор способов представления информации и программного инструментария.
После создания модели необходимо, в зависимости от выбранного программного продукта, определить форму представления информации.
В большинстве СУБД данные можно хранить в двух видах:
- с использованием форм;
- без использования форм.
Форма – это созданный пользователем графический интерфейс для ввода данных в базу.
V этап. Синтез компьютерной модели объекта.
В процессе создания компьютерной модели можно выделить некоторые стадии, типичные для любой СУБД.
Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.
Стадия 2. Создание исходной таблицы или таблиц.
Создавая исходную таблицу, необходимо указать имя и тип каждого поля. Имена полей не должны повторяться внутри одной таблицы. В процессе работы с БД можно дополнять таблицу новыми полями. Созданную таблицу необходимо сохранить, дав ей имя, уникальное в пределах создаваемой базы.
При проектировании таблиц, рекомендуется руководствоваться следующими основными принципами:
1. Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами. Когда определенная информация хранится только в одной таблице, то и изменять ее придется только в одном месте. Это делает работу более эффективной, а также исключает возможность несовпадения информации в разных таблицах. Например, в одной таблице должны содержаться адреса и телефоны клиентов.
2. Каждая таблица должна содержать информацию только на одну тему. Сведения на каждую тему обрабатываются намного легче, если они содержатся в независимых друг от друга таблицах. Например, адреса и заказы клиентов лучше хранить в разных таблицах, с тем, чтобы при удалении заказа информация о клиенте осталась в базе данных.
3. Каждая таблица должна содержать необходимые поля. Каждое поле в таблице должно содержать отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить, что каждое поле должно быть связано с темой таблицы. Не рекомендуется включать в таблицу данные, которые являются результатом выражения. В таблице должна присутствовать вся необходимая информация. Информацию следует разбивать на наименьшие логические единицы (Например, поля "Имя" и "Фамилия", а не общее поле "Имя").
4. База данных должна иметь первичный ключ. Это необходимо для того, чтобы СУБД могла связать данные из разных таблиц, например, данные о клиенте и его заказы.
Стадия 3. Создание экранных форм.
Первоначально необходимо указать таблицу, на базе которой будет создаваться форма. Ее можно создавать при помощи мастера форм, указав, какой вид она должна иметь, или самостоятельно. При создании формы можно указывать не все поля, которые содержит таблица, а только некоторые из них. Имя формы может совпадать с именем таблицы, на базе которой она создана. На основе одной таблицы можно создать несколько форм, которые могут отличаться видом или количеством используемых из данной таблицы полей. После создания форму необходимо сохранить. Созданную форму можно редактировать, изменяя местоположение, размеры и формат полей.
Стадия 4. Заполнение БД.
Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE – в виде формы.
VI этап. Работа с созданной базой данных.
Работа с БД включает в себя следующие действия:
-поиск необходимых сведений;
-вывод на печать;
-изменение и дополнение данных.
ГЛАВА III. СУБД Microsoft Access.
Microsoft Access – одна из наиболее популярных СУБД для операционной системы Microsoft Windows . Кроме того, СУБД Access является мощной платформой разработки с гибкой и функциональной интегрированной средой. Microsoft Access может использоваться как инструмент для разработки и развертывания широкопредметных информационных бизнес-систем.
В Access используются следующие основные типы полей:
- текстовый: предназначен для текстовой информации и чисел, когда нет необходимости выполнения математических операций с ними;
- числовой: предназначен для чисел при использовании их в математических расчетах;
- MEMO: предназначен для хранения произвольного текста или комментариев (длиной до 64000 символов);
- денежный: предназначен для хранения чисел, отражающих денежные суммы;
- дата/время: предназначен для хранения информации о дате и времени;
- счетчик: специальное числовое поле, предназначенное для автоматического добавления уникального номера текущей записи в таблице данных.
- логический: предназначен для хранения всего двух значений “Истина” и “Ложь”;
- поле объекта OLE: предназначено для хранения объектов, созданных другими приложениями (рисунки, графики, диаграммы).
В Microsoft Access существует несколько способов отобрать только требуемые данные при выполнении поиска конкретного значения, одной записи или группы записей.
С помощью диалогового окна “Поиск” легко найти конкретные записи или определенные значения в полях. При обнаружении каждого вхождения требуемого элемента выполняется перемещение по записям. Если нужно заменить конкретные обнаруженные при поиске значения, следует воспользоваться диалоговым окном “Замена”.
Запросы дают возможность работать с конкретным набором записей, которые удовлетворяют условиям, заданным для одной или нескольких таблиц базы данных. При выполнении запроса становится возможной независимая работа с этим набором записей в конкретной форме или в объекте в режиме таблицы.
Сортировка дает возможность упорядочить строки в таблице согласно содержимому одного или нескольких столбцов. Для сортировки выбирается поле, по которому будет осуществляться сортировка, и нажимается кнопка “Сортировка по возрастанию” или “Сортировка по убыванию” на панели инструментов.
Проектирование баз данных — обширная тема, но от вас не потребуется многого, чтобы изучить основы и иметь представление о правильной структуре баз данных. Может быть, наиболее важным этапом проектирования базы данных является само его начало и мозговой штурм. Это то, что позволяет любому разработчику получить всю необходимую информацию заранее и реализовывать задуманное по мере необходимости. Только имея всю необходимую информацию для проектирования, можно создать эффективную базу данных с правильно связанными таблицами.
Любая база данных должна быть эффективной и масштабируемой. Данные постоянно редактируются, добавляются, удаляются, поэтому важным будет содержать базу данных организованной таким образом, чтобы поддерживать этот постоянно изменяющийся набор данных. Убедитесь, чтобы в создаваемой базе данных удалялась только та информация, которая должна, не дублировались бы записи и можно было бы ссылаться на другие данных легко и просто.
ГОСТ
Полная разработка БД состоит из концептуального, логического и физического проектирования БД.
Концептуальное проектирование БД
Процесса проектирования БД начинается с первой фазы – создания концептуальной модели данных для анализируемой части организации.
Для проектирования сложных БД, которые содержат большое количество атрибутов, используется так называемый нисходящий подход.
Начинается нисходящий подход с разработки моделей данных, содержащих некоторое количество высокоуровневых сущностей и связей. Продолжается работа серией нисходящих уточнений низкоуровневых сущностей, атрибутов и связей, которые к ним относятся.
Нисходящий подход демонстрирует концепция ER-модели (модель "сущность – связь"), которая была предложена П. Ченом и является самой популярной технологией высокоуровневого моделирования данных.
Модель "сущность — связь" является семантической моделью.
Семантическое моделирование данных не зависит от представления данных в компьютере и связано с их смысловым содержанием.
Построение общей концептуальной модели данных состоит из таких этапов:
- Выделяются локальные представления, которые обычно соответствуют относительно независимым данным. Каждое подобное представление проектируется в виде подзадачи.
- Формулируются сущности, которые описывают локальную предметную область проектируемой базы данных, и описываются атрибуты, которые составляют структуру каждой сущности.
- Выделяются ключевые атрибуты.
- Специфицируются связи между сущностями. Удаляются избыточные связи.
- Анализируются и добавляются неключевые атрибуты.
- Объединяются локальные представления.
Концептуальная модель данных организации, созданная таким образом, становится источником информации для второй фазы проектирования – логического проектирования базы данных.
Готовые работы на аналогичную тему
Логическое проектирование БД
Вторая фаза проектирования БД заключается в создании логической модели данных для исследуемой части организации.
Логическую модель, которая отражает особенности представления о функционировании организации одновременно многими типами пользователей, называют глобальной логической моделью данных.
Проектирование БД должно опираться на определенную модель данных (реляционную, сетевую, иерархическую), которую определяют типом той информационной системы СУБД, которая предполагается для реализации.
Концептуальное и логическое проектирование являются итеративными процессами, включающими ряд уточнений, которые продолжаются до тех пор, пока разработчик не получит продукт, наиболее соответствующий структуре организации.
Физическое проектирование базы данных
Третья фаза проектирования БД заключается в создании описания системы управления базой данных ориентированной модели базы данных.
Действия, которые выполняются на этом этапе, являются слишком специфичными для разных моделей данных, вследствие чего трудно поддаются обобщению.
Рассмотрим реляционную модель данных. В таком случае при физическом проектировании:
Читайте также: