Проектирование баз данных
Основные понятия о базах данных и СУБД
Информационная система (ИС) – это система, построенная на базе компьютерной техники, предназначенная для хранения, поиска, обработки и передачи значительных объемов информации, имеющая определенную практическую сферу применения.
База данных – это ИС, которая хранится в электронном виде.
База данных (БД) – организованная совокупность данных, предназначенная для длительного хранения во внешней памяти ЭВМ, постоянного обновления и использования.
БД служат для хранения и поиска большого объёма информации. Примеры баз данных: записная книжка, словари, справочники, энциклопедии и т.д.
Классификация баз данных:
1. По характеру хранимой информации:
- Фактографические – содержат краткие сведения об описываемых объектах, представленных в строго определённом формате (картотеки, н-р: БД книжного фонда библиотеки, БД кадрового состава учреждения),
- Документальные – содержат документы (информацию) самого разног типа: текстового, графического, звукового, мультимедийного (архивы, н-р: справочники, словари, БД законодательных актов в области уголовного права и др.)
2. По способу хранения данных:
- Централизованные (хранятся на одном компьютере),
- Распределенные (используются в локальных и глобальных компьютерных сетях).
3. По структуре организации данных:
- Реляционные (табличные),
- Нереляционные.
Термин «реляционный» (от лат. relatio – отношение) указывает на то, что такая модель хранения данных построена на взаимоотношении составляющих её частей. Реляционная база данных, по сути, представляет собой двумерную таблицу . Каждая строка такой таблицы называется записью. Столбцы таблицы называются полями: каждое поле характеризуется своим именем и топом данных. Поле БД – это столбец таблицы, содержащий значения определенного свойства.
Свойства реляционной модели данных:
Каждый элемент таблицы – один элемент данных;
Все поля таблицы являются однородными, т.е. имеют один тип;
Одинаковые записи в таблице отсутствуют;
Порядок записей в таблице может быть произвольным и может характеризоваться количеством полей, типом данных.
Иерархической называется БД, в которой информация упорядоченная следующим образом: один элемент считается главным, остальные – подчинёнными. В иерархической базе данных записи упорядочиваются в определенную последовательность, как ступеньки лестницы, и поиск данных может осуществляться последовательным «спуском» со ступени на ступень. Данная модель характеризуется такими параметрами, как уровни, узлы, связи. Принцип работы модели таков, что несколько узлов более низкого уровня соединяются при помощи связи с одним узлом более высокого уровня.
Узел – информационная модель элемента, находящегося на данном уровне иерархии.
Свойства иерархической модели данных:
Несколько узлов низшего уровня связано только с одним узлом высшего уровня;
Иерархическое дерево имеет только одну вершину (корень), не подчинено никакой другой вершине;
Каждый узел имеет своё имя (идентификатор);
Существует только один путь от корневой записи к более частной записи данных.
Иерархической базой данных является Каталог папок Windows, с которым можно работать, запустив Проводник. Верхний уровень занимает папка Рабочий стол. На втором уровне находятся папки Мой компьютер, Мои документы, Сетевое окружение и Корзина, которые представляют собой потомков папки Рабочий стол, будучи между собой близнецами. В свою очередь, папка Мой компьютер – предок по отношению к папкам третьего уровня, папкам дисков (Диск 3,5(А:), С:, D:, E:, F:) и системным папкам (Принтеры, Панель управления и др.).
Сетевой называется БД, в которой к вертикальным иерархическим связям добавляются горизонтальные связи. Любой объект может быть главным и подчинённым.
Сетевой базой данных фактически является Всемирная паутина глобальной компьютерной сети Интернет. Гиперссылки связывают между собой сотни миллионов документов в единую распределенную сетевую базу данных.
Программное обеспечение, предназначенное для работы с базами данных, называется система управления базами данных (СУБД). СУБД используются для упорядоченного хранения и обработки больших объемов информации.
Система управления базами данных (СУБД) – это система, обеспечивающая поиск, хранение, корректировку данных, формирование ответов на запросы. Система обеспечивает сохранность данных, их конфиденциальность, перемещение и связь с другими программными средствами.
Основные действия, которые пользователь может выполнять с помощью СУБД:
Создание структуры БД;
Заполнение БД информацией;
Изменение (редактирование) структуры и содержания БД;
Поиск информации в БД;
Сортировка данных;
Защита БД;
Проверка целостности БД.
Современные СУБД дают возможность включать в них не только текстовую и графическую информацию, но и звуковые фрагменты и даже видеоклипы.
Простота использования СУБД позволяет создавать новые базы данных, не прибегая к программированию, а пользуясь только встроенными функциями. СУБД обеспечивают правильность, полноту и непротиворечивость данных, а также удобный доступ к ним.
Популярные СУБД - FoxPro, Access for Windows, Paradox.
Таким образом, необходимо различать собственно базы данных (БД) – упорядоченные наборы данных, и системы управления базами данных (СУБД) – программы, управляющие хранением и обработкой данных. Например, приложение Access, входящее в офисный пакет программ Microsoft Office, является СУБД, позволяющей пользователю создавать и обрабатывать табличные базы данных.
Принципы построения систем управления баз данных следуют из требований, которым должна удовлетворять организация баз данных:
- Производительность и готовность. Запросы от пользователя базой данных удовлетворяются с такой скоростью, которая требуется для использования данных. Пользователь быстро получает данные всякий раз, когда они ему необходимы.
- Минимальные затраты. Низкая стоимость хранения и использования данных, минимизация затрат на внесение изменений.
- Простота и легкость использования. Пользователи могут легко узнать и понять, какие данные имеются в их распоряжении. Доступ к данным должен быть простым, исключающим возможные ошибки со стороны пользователя.
- Простота внесения изменений. База данных может увеличиваться и изменяться без нарушения имеющихся способов использования данных.
- Возможностьпоиска. Пользователь базы данных может обращаться с самыми различными запросами по поводу хранимых в ней данных. Для реализации этого служит так называемый язык запросов.
- Целостность . Современные базы данных могут содержать данные, используемые многими пользователями. Очень важно, чтобы в процессе работы элементы данных и связи между ними не нарушались. Кроме того, аппаратные ошибки и различного рода случайные сбои не должны приводить к необратимым потерям данных. Значит, система управления данными должна содержать механизм восстановления данных.
- Безопасность и секретность. Под безопасностью данных понимают защиту данных от случайного или преднамеренного доступа к ним лиц, не имеющих на это права, от неавторизированной модификации (изменения) данных или их разрушения. Секретность определяется как право отдельных лиц или организаций решать, когда, как какое количество информации может быть передано другим лицам или организациям.
Далее на примере одной из самых распространенных систем управления базами данных – Microsoft Access входит в состав популярного пакета Microsoft Office – мы познакомимся с основными типами данных, способами создания баз данных и с приемами работы с базами данных.
Проектирование баз данных
Как и любой программный продукт, база данных обладает собственным жизненным циклом (ЖЦБД). Главной составляющей в жизненном цикле БД является создание единой базы данных и программ, необходимых для ее работы.
ЖЦБД включает в себя следующие основные этапы:
1. Планирование разработки базы данных;
2. Определение требований к системе;
3. Сбор и анализ требований пользователей:
4. Проектирование базы данных:
Концептуальное проектирование базы данных – создание концептуальной модели данных, то есть информационной модели. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Чаще всего концептуальная модель базы данных включает в себя: описание информационных объектов, или понятий предметной области и связей между ними; описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними;
Логическое проектирование базы данных – создание логической модели данных; создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных логическая модель - набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.
На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
Физическое проектирование базы данных – создание схемы базы данных для конкретной СУБД, создание описания СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным, разработка средств защиты данных), создание индексов и т.д.;
5. Разработка приложений:
Проектирование транзакций (группа инструкций SQL (набор команд), исполняемых как единое целое);
Проектирование пользовательского интерфейса;
6. Реализация;
8. Тестирование;
9. Эксплуатация и сопровождение:
Анализ функционирования и поддержка исходного варианта БД;
Адаптация, модернизация и поддержка переработанных вариантов.
Проектирование баз данных – процесс создания схемы базы данных и определения необходимых ограничений целостности (соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам).
Основные задачи проектирования баз данных:
Обеспечение хранения в БД всей необходимой информации.
Обеспечение возможности получения данных по всем необходимым запросам.
Сокращение избыточности и дублирования данных.
Обеспечение целостности базы данных.
Прежде чем приступать к созданию базы данных, необходимо потратить какое-то время на ее проектирование .
Основная цель проектирования баз данных (БД) – это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Так называемый, «чистый» проект БД («каждый факт в одном месте») можно создать, используя методологию нормализации отношений. Нормализация должна использоваться на завершающей проверочной стадии проектирования БД.
Плохая проработка структуры базы почти всегда приводит к бесполезным затратам времени на ее переработку в дальнейшем. Опытные разработчики уделяют проектированию баз данных не меньше времени, чем их созданию. В целом же разработка базы данных включает следующие этапы:
1. Определение назначения базы данных.
2. Принятие решения о том, какие исходные данные база данных должна содержать.
3. Определение исходных таблиц базы данных.
4. Определение полей, которые будут входить в таблицы, и выбор полей, содержащих уникальные значения.
5. Назначение связей между таблицами и окончательный просмотр получившейся структуры.
6. Создание таблиц, связывание их между собой и экспериментальное наполнение базы пробными данными.
7. Создание форм, отчетов и запросов для операций с введенными данными.
Определение назначения базы данных
Разработка каждой базы данных начинается с изучения проблемы, которую она должна разрешить, или потребности, которую она должна удовлетворить.
В качестве примера попробуем создать простейшую базу данных библиотеки художественной литературы «Библиотека». База данных предназначена для хранения данных о приобретенных библиотекой книгах, информации о местонахождении отдельных экземпляров каждого издания и сведений о читателях.
Выбор информации, включаемой в базу
Для ведения библиотечных каталогов, организации поиска требуемых книг и библиотечной статистики в базе должны храниться сведения, большая часть которых размещаются в аннотированных каталожных карточках. Анализ запросов на литературу показывает, что для поиска подходящих книг (по тематике, автору, издательству и т.п.) и отбора нужного (например, по аннотации) следует выделить следующие атрибуты каталожной карточки:
2. Название книги.
3. Место издания (город).
4. Издательство (название издательства).
5. Год выпуска.
6. Аннотация.
К атрибутам, позволяющим охарактеризовать места хранения отдельных экземпляров книг, можно отнести:
1. Номер комнаты (помещения для хранения книг).
2. Номер стеллажа в комнате.
3. Номер полки на стеллаже.
4. Номер (инвентарный номер книги).
5. Дата приобретения.
6. Дата размещения конкретной книги на конкретном месте.
7. Дата изъятия книги с установленного места.
К атрибутам, позволяющим охарактеризовать читателей, можно отнести:
1. Номер читательского билета (формуляра).
2. Фамилия читателя.
3. Имя читателя.
4. Отчество читателя.
5. Адрес читателя.
6. Телефон читателя.
7. Дата выдачи читателю конкретной книги.
8. Срок, на который конкретная книга выдана читателю.
9. Дата возврата книги.
Определение исходных таблиц
Анализ определенных выше объектов и атрибутов позволяет определить для проектируемой базы данных следующие таблицы для построения базы данных:
2. Книги . Таблица предназначена для хранения сведений о книгах.
3. Издательства .Таблица предназначена для хранения сведений об издательствах.
4. Хранилище . Таблица предназначена для описания места хранения книг.
5. Выдача .Таблица предназначена для хранения сведений о выданных книгах.
6. Читатели .Таблица предназначена для хранения сведений о читателях библиотеки.
Выбор необходимых полей таблиц
Определив набор таблиц, входящих в базу, надо продумать, какая информация о каждом объекте будет входить в каждую из таблиц. Каждое поле должно принадлежать одной отдельной таблице. В то же время информация в каждом поле должна быть структурно-элементарной, то есть она должна храниться в полях в виде наименьших логических компонентов.
Исходя из вышесказанного, определяем поля в выбранных таблицах и тип хранимых данных.
Книги:
· код книги – числовое поле, предназначено для однозначного определения каждой конкретной книги в базе данных;
· название книги
· аннотация – текстовое поле;
· дата издания ;
· дата поступления в библиотеку ;
· место хранения
.
Издательства:
· код издательства – числовое поле, предназначено для однозначного определения каждого конкретного издательства в базе данных;
· название издательства – символьное поле, не более 256 символов;
· город, где расположено издательство – символьное поле, не более 25 символов.
Хранилище:
· код места – числовое поле, предназначено для однозначного определения каждой конкретной полки в базе данных;
· номер комнаты – числовое поле;
· номер стеллажа – числовое поле;
· номер полки – числовое поле.
Выдача:
· код выдачи – числовое поле, предназначено для однозначного определения каждой конкретной выдачи в базе данных;
· номер выданной книги – числовое поле;
· код читателя – числовое поле;
· дата выдачи ;
· срок выдачи (количество дней);
· дата возврата .
Читатели:
· номер читательского билета – числовое поле, предназначено для однозначного определения каждого конкретного читателя в базе данных;
· фамилия
· имя – символьное поле, не более 50 символов;
· отчество – символьное поле, не более 50 символов;
· адрес – символьное поле, не более 256 символов;
· телефон – символьное поле, не более 20 символов.
Выбор уникальных полей
В реляционной базе данных таблицы могут быть связаны друг с другом. Эта связь устанавливается с помощью уникальных полей. Уникальные поля – это такие поля, в которых значения не могут повторяться. Например, серия и номер паспорта однозначно идентифицируют любого человека, имеющего паспорт. Такое поле (или комбинация полей), которое однозначно идентифицирует запись в таблице, называется первичным ключом .В качестве поля первичного ключа также может выступать порядковый номер записи в каталоге, табельный номер работника предприятия, артикул товара в розничной торговле.
Для нашей базы данных первичными ключами являются следующие поля:
· Книги – код книги .
· Издательства – код издательства .
· Хранилище – код места .
· Выдача – код выдачи .
· Читатели – номер билета .
Назначение связей между таблицами
Межтабличные связи увязывают две таблицы с помощью общего поля, которое имеется в обеих таблицах. Существуют три типа таких связей:
· один-к-одному – каждая запись таблицы А не может быть связана более чем с одной записью таблицы Б;
· один-ко-многим – одна запись в таблице А может быть связана со многими записями таблицы Б (например, в каждом классе может быть много учеников);
· многие-ко-многим – каждая запись в таблице А может быть связана со многими записями в таблице Б, а каждая запись в таблице Б – со многими записями в таблице А (например, у каждого учащегося может быть несколько преподавателей, а у каждого преподавателя может быть много учеников).
Реляционные базы данных не позволяют создавать связи типа многие-ко-многим напрямую. Однако в реальной жизни такие связи встречаются очень часто, поэтому их реализуют через вспомогательные таблицы, увязывая несколько таблиц связями типа один-ко-многим.
Для того чтобы связать одну таблицу с другой, надо ввести во вторую таблицу поле первичного ключа из первой таблицы, т.е. ввести во вторую таблицу внешний ключ . Связь двух таблиц выполняется подключением первичного ключа главной таблицы (находящейся на стороне отношения «один») к такому же полю внешнего ключа связанной таблицы (находящейся на стороне отношения «многие»). Поле внешнего ключа в связанной таблице должно иметь тот же тип данных, что и первичный ключ в родительской таблице, но с одним исключением. Если первичный ключ главной таблицы имеет тип данных «Счетчик», то поле внешнего ключа в связанной таблице должно иметь тип данных «Числовой».
В нашей базе данных установим следующие типы связей между таблицами:
1. Авторы – Книги. Здесь связь многие-ко-многим , у любого автора может быть более одной книги, и любая книга может быть написана несколькими авторами. Поэтому вводим вспомогательную таблицу «Авторы–книги» со следующими полями:
· код книги .
2. Книги – Издательства. Здесь связь многие-ко-многим , любая книга может быть издана несколькими издательствами и любое издательство издает не одну книгу. Поэтому вводим еще одну вспомогательную таблицу «Книги–издательства» со следующими полями:
· код книги ;
· код издательства .
3. Хранилище – Книги. Здесь связь один-ко-многим , на одной полке можно расставить множество книг, но любая книга может быть только на одной полке в хранилище. Поэтому поле «Место хранения» в таблице «Книги» определяем как внешний ключ, и связываем таблицы «Хранилище» и «Книги» первичным ключом «Код места» и внешним ключом «Место хранения».
4. Книги – Выдача. Здесь связь один-ко-многим , т.е. одна и та же книга может быть выдана несколько раз в разные даты разным читателям. Поэтому поле «Номер выданной книги» в таблице «Выдача» определяем как внешний ключ, и связываем таблицы «Книги» и «Выдача» первичным ключом «Код книги» и внешним ключом «Номер выданной книги».
5. Читатели – Выдача. Здесь связь один-ко-многим , т.е. одна и та же книга может быть выдана несколько раз разным читателям в разные сроки. Поэтому поле «Код читателя» в таблице «Выдача» определяем как внешний ключ, и связываем таблицы «Читатели» и «Выдача» первичным ключом «Номер читательского билета» и внешним ключом «Код читателя».
Нормализация отношений
Закончив проектирование таблиц и выявив связи, существующие между ними, необходимо тщательно перепроверить полученную структуру, прежде чем приступать к созданию таблиц и вводу информации. Нормализация отношений позволяет существенно сократить объем хранимой информации и устранить аномалии в организации хранения данных.
Правило 1: каждое поле таблицы должно представлять уникальный тип информации.
В спроектированной нами базе данных нет полей в разных таблицах, содержащих одну и ту же информацию (за исключением внешних ключей).
Правило 2: каждая таблица должна иметь уникальный идентификатор, или первичный ключ, который может состоять из одного или нескольких полей.
В спроектированной нами базе данных все таблицы (за исключением вспомогательных «Авторы – книги» и «Издательства – книги») содержат первичный ключ.
Правило 3: для каждого значения первичного ключа значения в столбцах данных должны относиться к объекту таблицы и полностью его описывать.
Это правило используется двояко. Во-первых, в таблице не должно быть данных, не относящихся к объекту, определяемому первичным ключом. Например, хотя для каждой книги требуется информация о ее авторе, но автор является самостоятельным объектом, и данные о нем должны находиться в соответствующей таблице. Во-вторых, данные в таблице должны полностью описывать объект.
Правило 4: должна быть возможность изменять значения любого поля (не входящего в первичный ключ) без воздействия на данные других полей.
Последнее правило позволяет проверить, не возникнут ли проблемы при изменении данных в таблицах. Поскольку в спроектированной нами базе данные, содержащиеся в разных полях таблиц, нигде не повторяются, мы имеем возможность корректировать значения любых полей (за исключением первичных ключей).
Наполнение базы данных, создание форм и отчетов
Чтобы определить, насколько структура базы данных соответствует поставленной задаче и насколько удобно с этой базой работать, необходимо ввести несколько простейших записей. Обычно после этого приходится возвращаться к структуре базы и настраивать ее в соответствии с тем, какие результаты были получены в ходе такого теста.
На заключительном этапе создают формы для ввода информации в базу, отчеты для вывода информации и запросы, с помощью которых производится выборка информации из нескольких таблиц. Если база предназначена для передачи другим пользователям, то, скорее всего, необходимо, чтобы кто-то из посторонних людей проверил, насколько удобно работать с формами и отчетами.
Полученная схема данных разработанной БД в MS Access представлена на рис. 4.1.
Рис. 4.1. Схема данных разработанной БД в Microsoft Access
1. Дайте определение информационной системы.
2. Поясните понятие базы данных.
3. Что такое предметная область?
4. Дайте определение СУБД.
5. Что такое модель данных?
6. Поясните основные принципы реляционной модели данных.
7. Поясните особенности СУБД Microsoft Access.
8. Каковы основные объекты базы данных Access?
9. Поясните структуру таблицы Access.
10. Поясните понятия: запрос, форма, отчет, страница доступа к данных, макрос, модуль.
11. Каковы основные этапы проектирования базы данных?
12. Каким образом осуществляется выбор информации, включаемой в базу данных?
13. Поясните понятия: первичный ключ, внешний ключ.
14. Каково назначение связей между таблицами?
15. Поясните основные типы связей между таблицами.
16. В чем заключается нормализация отношений базы данных?
При разработке БД можно выделить следующие этапы работы.
I этап. Постановка задачи.
На этом этапе формируется задание по созданию БД. В нем подробно описывается состав базы, назначение и цели ее создания, а также перечисляется, какие виды работ предполагается осуществлять в этой базе данных (отбор, дополнение, изменение данных, печать или вывод отчета и т. д).
II этап. Анализ объекта.
На этом этапе рассматривается, из каких объектов может состоять БД, каковы свойства этих объектов. После разбиения БД на отдельные объекты необходимо рассмотреть свойства каждого из этих объектов, или, другими словами, установить, какими параметрами описывается каждый объект. Все эти сведения можно располагать в виде отдельных записей и таблиц. Далее необходимо рассмотреть тип данных каждой отдельной единицы записи. Сведения о типах данных также следует занести в составляемую таблицу.
III этап. Синтез модели.
На этом этапе по проведенному выше анализу необходимо выбрать определенную модель БД. Далее рассматриваются достоинства и недостатки каждой модели и сопоставляются с требованиями и задачами создаваемой БД. После такого анализа выбирают ту модель, которая сможет максимально обеспечить реализацию поставленной задачи. После выбора модели необходимо нарисовать ее схему с указанием связей между таблицами или узлами.
IV этап. Выбор способов представления информации и программного инструментария.
После создания модели необходимо, в зависимости от выбранного программного продукта, определить форму представления информации.
В большинстве СУБД данные можно хранить в двух видах:
- с использованием форм;
- без использования форм.
Форма – это созданный пользователем графический интерфейс для ввода данных в базу.
V этап. Синтез компьютерной модели объекта.
В процессе создания компьютерной модели можно выделить некоторые стадии, типичные для любой СУБД.
Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.
Стадия 2. Создание исходной таблицы или таблиц.
Создавая исходную таблицу, необходимо указать имя и тип каждого поля. Имена полей не должны повторяться внутри одной таблицы. В процессе работы с БД можно дополнять таблицу новыми полями. Созданную таблицу необходимо сохранить, дав ей имя, уникальное в пределах создаваемой базы.
1. Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами. Когда определенная информация хранится только в одной таблице, то и изменять ее придется только в одном месте. Это делает работу более эффективной, а также исключает возможность несовпадения информации в разных таблицах. Например, в одной таблице должны содержаться адреса и телефоны клиентов.
2. Каждая таблица должна содержать информацию только на одну тему. Сведения на каждую тему обрабатываются намного легче, если они содержатся в независимых друг от друга таблицах. Например, адреса и заказы клиентов лучше хранить в разных таблицах, с тем, чтобы при удалении заказа информация о клиенте осталась в базе данных.
3. Каждая таблица должна содержать необходимые поля. Каждое поле в таблице должно содержать отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить, что каждое поле должно быть связано с темой таблицы. Не рекомендуется включать в таблицу данные, которые являются результатом выражения. В таблице должна присутствовать вся необходимая информация. Информацию следует разбивать на наименьшие логические единицы (Например, поля "Имя" и "Фамилия", а не общее поле "Имя").
4. База данных должна иметь первичный ключ. Это необходимо для того, чтобы СУБД могла связать данные из разных таблиц, например, данные о клиенте и его заказы.
Стадия 3. Создание экранных форм.
Первоначально необходимо указать таблицу, на базе которой будет создаваться форма. Ее можно создавать при помощи мастера форм, указав, какой вид она должна иметь, или самостоятельно. При создании формы можно указывать не все поля, которые содержит таблица, а только некоторые из них. Имя формы может совпадать с именем таблицы, на базе которой она создана. На основе одной таблицы можно создать несколько форм, которые могут отличаться видом или количеством используемых из данной таблицы полей. После создания форму необходимо сохранить. Созданную форму можно редактировать, изменяя местоположение, размеры и формат полей.
Стадия 4. Заполнение БД.
Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE – в виде формы.
VI этап. Работа с созданной базой данных.
Работа с БД включает в себя следующие действия:
- поиск необходимых сведений;
- сортировка данных;
- отбор данных;
- вывод на печать;
- изменение и дополнение данных.
Основные задачи проектирования баз данных
Основные задачи:
- Обеспечение хранения в БД всей необходимой информации.
- Обеспечение возможности получения данных по всем необходимым запросам.
- Сокращение избыточности и дублирования данных.
- Обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д..
Основные этапы проектирования баз данных
Концептуальное (инфологическое) проектирование - построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных . Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.
Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам .
Чаще всего концептуальная модель базы данных включает в себя:
- описание информационных объектов, или понятий предметной области и связей между ними.
- описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.
Логическое (даталогическое) проектирование - создание схемы базы данных на основе конкретной модели данных , например, реляционной модели данных . Для реляционной модели данных даталогическая модель - набор схем отношений , обычно с указанием первичных ключей , а также «связей» между отношениями, представляющих собой внешние ключи .
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.
На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
Физическое проектирование
Физическое проектирование - создание схемы базы данных для конкретной СУБД . Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.
Нормализация
При проектировании реляционных баз данных обычно выполняется так называемая нормализация.
Модели «сущность-связь»
Модель «сущность-связь» (англ. “Entity-Relationship model” ), или ER-модель, предложенная П. Ченом в 1976 г., является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме, с использованием оригинальной нотации П. Чена, называемой ER-диаграмма , либо с использованием других графических нотаций (Crow"s Foot , Information Engineering и др.).
Основные преимущества ER-моделей:
- наглядность;
- модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;
- ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).
Основные элементы ER-моделей:
- объекты (сущности);
- атрибуты объектов;
- связи между объектами.
Сущность - объект предметной области, имеющий атрибуты.
Связь между сущностями характеризуется:
- типом связи (1:1, 1:N, N:М);
- классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности - обязательный, иначе - необязательный.
Семантические модели
Семантическая модель (концептуальная модель, инфологическая модель) – модель предметной области, предназначенная для представления семантики предметной области на самом высоком уровне абстракции. Это означает, что устранена или минимизирована необходимость использовать понятия «низкого уровня», связанные со спецификой физического представления и хранения данных.
Дейт К. Дж. Введение в системы баз данных. - 8-е изд. - М.: «Вильямс», 2006:
Семантическое моделирование стало предметом интенсивных исследований с конца 1970-х годов. Основным побудительным мотивом подобных исследований (т.е. проблемой, которую пытались разрешить исследователи) был следующий факт. Дело в том, что системы баз данных обычно обладают весьма ограниченными сведениями о смысле хранящихся в них данных. Чаще всего они позволяют лишь манипулировать данными определенных простых типов и определяют некоторые простейшие ограничения целостности, наложенные на эти данные. Любая более сложная интерпретация возлагается на пользователя. Однако было бы замечательно, если бы системы могли обладать немного более широким объемом сведений и несколько интеллектуальнее отвечать на запросы пользователя, а также поддерживать более сложные (т.е. более высокоуровневые) интерфейсы пользователя.
[…]
Идеи семантического моделирования могут быть полезны как средство проектирования базы данных даже при отсутствии их непосредственной поддержки в СУБД.
Наиболее известным представителем класса семантических моделей является модель «сущность-связь» (ER-модель).
Литература
- Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. - 8-е изд. - М .: «Вильямс», 2006. - 1328 с. - ISBN 0-321-19784-4
- Когаловский М.Р. Перспективные технологии информационных систем. - М .: ДМК Пресс; Компания АйТи, 2003. - 288 с. - ISBN 5-279-02276-4
- Когаловский М.Р. Энциклопедия технологий баз данных. - М .: Финансы и статистика, 2002. - 800 с. - ISBN 5-279-02276-4
- Кузнецов С. Д. Основы баз данных. - 2-е изд. - М .: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. - 484 с. - ISBN 978-5-94774-736-2
- Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. - 3-е изд. - М .: «Вильямс», 2003. - 1436 с. - ISBN 0-201-70857-4
- Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. - М .: «Вильямс», 2003. - 1088 с. - ISBN 5-8459-0384-X
См. также
- Методы проектирования
Ссылки
- Модель "сущность-связь" – шаг к единому представлению о данных - Citforum
- Расширение реляционной модели для лучшего отражения семантики - Citforum
- Пособие по проектированию баз данных сайтов "для начинающих"
- Метод проектирования логической структуры реляционной БД без нормализации таблиц
Примечания
Wikimedia Foundation . 2010 .
Смотреть что такое "Проектирование баз данных" в других словарях:
Администратор базы данных лицо, отвечающее за выработку требований к базе данных, её проектирование, реализацию, эффективное использование и сопровождение, включая управление учётными записями пользователей БД и защиту от несанкционированного… … Википедия
- (англ. database refactoring) это простое изменение в схеме базы данных, которое способствует улучшению ее проекта при сохранении функциональной и информационной семантики. Иными словами, следствием рефакторинга базы данных не может быть… … Википедия
ПРОЕКТИРОВАНИЕ - одна из форм опережающего отражения действительности, процесс создания прообраза (прототипа) предполагаемого объекта, явления или процесса посредством специфич. методов. П. является конкретной формой проявления прогностич. функции управления,… … Российская социологическая энциклопедия
Запрос «БД» перенаправляется сюда; см. также другие значения. База данных представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов),… … Википедия
